From codesite-noreply at google.com Thu Apr 2 11:42:13 2015 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Thu, 02 Apr 2015 11:42:13 +0000 Subject: [xmonad] Issue 598 in xmonad: Join stackage Message-ID: <0-3425899027203913298-7621895015282087317-codesite-noreply=google.com@googlecode.com> Status: Accepted Owner: nome... at gmail.com New issue 598 by nome... at gmail.com: Join stackage https://code.google.com/p/xmonad/issues/detail?id=598 Currently, xmonad does not build against the packages in the latest Stackage LTS release, in particular utf8-string-1. It would be great if xmonad would join stackage so that such problems are detected early. It also gives you some QA for free: http://www.stackage.org/authors -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings From codesite-noreply at google.com Fri Apr 3 04:40:27 2015 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Fri, 03 Apr 2015 04:40:27 +0000 Subject: [xmonad] Issue 597 in xmonad: xmonad-contrib-0.11.4 does not compile In-Reply-To: <0-3425899027203913298-5220352385308706020-codesite-noreply=google.com@googlecode.com> References: <0-3425899027203913298-5220352385308706020-codesite-noreply=google.com@googlecode.com> Message-ID: <1-3425899027203913298-5220352385308706020-codesite-noreply=google.com@googlecode.com> Comment #1 on issue 597 by markwri... at internode.on.net: xmonad-contrib-0.11.4 does not compile https://code.google.com/p/xmonad/issues/detail?id=597 Patch to add import Control.Applicative Attachments: xmonad-contrib-0.11.4-import-Applicative.patch 918 bytes -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings From davama at gmail.com Tue Apr 7 03:45:33 2015 From: davama at gmail.com (Dave Macias) Date: Mon, 6 Apr 2015 23:45:33 -0400 Subject: [xmonad] xmonad: xmonad-extras 0.12 fails to build Message-ID: This is my first time posting here so i hope im doing this right. Just updated ghc to 7.10.1 and had to rebuild xmonad, xmonad-contrib, and xmobar. I also use xmonad-extras but it failed during the build. I tried using cabal and also from source but both give same output: $ cabal install xmonad-extras Resolving dependencies... Configuring xmonad-extras-0.12... Building xmonad-extras-0.12... Failed to install xmonad-extras-0.12 Build log ( /home/dvmacias/.cabal/logs/xmonad-extras-0.12.log ): Configuring xmonad-extras-0.12... Building xmonad-extras-0.12... Preprocessing library xmonad-extras-0.12... [1 of 2] Compiling XMonad.Util.WindowPropertiesRE ( XMonad/Util/WindowPropertiesRE.hs, dist/build/XMonad/Util/WindowPropertiesRE.o ) [2 of 2] Compiling XMonad.Actions.Volume ( XMonad/Actions/Volume.hs, dist/build/XMonad/Actions/Volume.o ) XMonad/Actions/Volume.hs:173:23: Ambiguous occurrence ?<*? It could refer to either ?XMonad.Actions.Volume.<*?, defined at XMonad/Actions/Volume.hs:66:4 or ?Prelude.<*?, imported from ?Prelude? at XMonad/Actions/Volume.hs:15:8-28 (and originally defined in ?GHC.Base?) XMonad/Actions/Volume.hs:173:43: Ambiguous occurrence ?<*? It could refer to either ?XMonad.Actions.Volume.<*?, defined at XMonad/Actions/Volume.hs:66:4 or ?Prelude.<*?, imported from ?Prelude? at XMonad/Actions/Volume.hs:15:8-28 (and originally defined in ?GHC.Base?) XMonad/Actions/Volume.hs:200:62: Ambiguous occurrence ?<*? It could refer to either ?XMonad.Actions.Volume.<*?, defined at XMonad/Actions/Volume.hs:66:4 or ?Prelude.<*?, imported from ?Prelude? at XMonad/Actions/Volume.hs:15:8-28 (and originally defined in ?GHC.Base?) XMonad/Actions/Volume.hs:215:32: Ambiguous occurrence ?<*? It could refer to either ?XMonad.Actions.Volume.<*?, defined at XMonad/Actions/Volume.hs:66:4 or ?Prelude.<*?, imported from ?Prelude? at XMonad/Actions/Volume.hs:15:8-28 (and originally defined in ?GHC.Base?) XMonad/Actions/Volume.hs:225:58: Ambiguous occurrence ?<*? It could refer to either ?XMonad.Actions.Volume.<*?, defined at XMonad/Actions/Volume.hs:66:4 or ?Prelude.<*?, imported from ?Prelude? at XMonad/Actions/Volume.hs:15:8-28 (and originally defined in ?GHC.Base?) cabal: Error: some packages failed to install: xmonad-extras-0.12 failed during the building phase. The exception was: ExitFailure 1 I got to look at the log but it just has what i pasted above. System is Arch 3.19.2-1-ARCH Any input is appreciated. Thanks dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From cwbell at mail.usf.edu Tue Apr 7 19:23:18 2015 From: cwbell at mail.usf.edu (Chris Bell) Date: Tue, 7 Apr 2015 15:23:18 -0400 Subject: [xmonad] Message passing between instances Message-ID: Hi all, I'm currently using multiple boxes in a convoluted extended desktop setup using Synergy. I have a script which, when I start X on the main box, connects via SSH to the secondary boxes and starts X and Xmonad. Then Synergy takes over and I can control all of the desktops from a single kbd/mouse. Overall, it seems to be working surprisingly well. I'm having trouble automating event/action synchronization post-startup. Specifically, I want to quit the Xmonad sessions on the secondary boxes when the primary quits. I have this currently implemented by killing the X server over ssh; an action about as graceful as throwing a brick through a window. Is there a builtin way to pass messages between Xmonad instances? So that, when I exit on the primary, it sends an 'exit' command to the secondaries, which then clean up and close. Preferably, I would like to extend this to synchronize xscreensaver activation, but that's not a major concern. If there isn't a builtin method, can anyone recommend a third-party application/feature which I can use to implement such functionality? I keep persistent SSH connections between the primary and all secondaries, so commands can be passed as necessary. All three boxes are running Xmonad 0.11 on bare metal - no desktop/session manager. Synergy setup and X initializations are done via a custom startx script. Thanks for all your help! Chris Bell Ph.D. Candidate, Teaching Assistant, Gentleman, Scholar, Penguin Wrangler University of South Florida College of Engineering Department of Computer Science and Engineering NarMOS Research Team, Official Daemon Charmer -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Tue Apr 7 20:05:55 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 7 Apr 2015 16:05:55 -0400 Subject: [xmonad] Message passing between instances In-Reply-To: References: Message-ID: On Tue, Apr 7, 2015 at 3:23 PM, Chris Bell wrote: > Is there a builtin way to pass messages between Xmonad instances? So that, > when I exit on the primary, it sends an 'exit' command to the secondaries, > which then clean up and close. Preferably, I would like to extend this to > synchronize xscreensaver activation, but that's not a major concern. > XMonad.Hooks.ServerMode is a proof-of-concept that needs some work to be practical (IIRC it can rearrange some commands if you add workspaces dynamically, and has other problems). xscreensaver has a remote-control protocol of sorts already; see xscreensaver-command. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From cwbell at mail.usf.edu Tue Apr 7 21:08:41 2015 From: cwbell at mail.usf.edu (Chris Bell) Date: Tue, 7 Apr 2015 17:08:41 -0400 Subject: [xmonad] Message passing between instances In-Reply-To: References: Message-ID: On Tue, Apr 7, 2015 at 4:05 PM, Brandon Allbery wrote: > XMonad.Hooks.ServerMode is a proof-of-concept that needs some work to be > practical Fantastic, thanks! I don't mind impractical; as long as it's not impossible. The 'quit-wm' function seems to work well enough as-is in my brief testing. At the moment, I'm only using simple commands, so hopefully it should prove 'practical enough'. > xscreensaver has a remote-control protocol of sorts already; Thanks for the heads up. I completely missed the `-display host:disp` argument: that should do exactly what I want. Thanks again for the help! Chris Bell Ph.D. Candidate, Teaching Assistant, Gentleman, Scholar, Penguin Wrangler University of South Florida College of Engineering Department of Computer Science and Engineering NarMOS Research Team, Official Daemon Charmer From byorgey at gmail.com Thu Apr 9 14:04:22 2015 From: byorgey at gmail.com (Brent Yorgey) Date: Thu, 09 Apr 2015 14:04:22 +0000 Subject: [xmonad] xmonad: xmonad-extras 0.12 fails to build In-Reply-To: References: Message-ID: It looks like XMonad.Actions.Volume defines an operator (<*), but as of base-4.8 an operator with that name has been added to the Prelude. The fix would be to either (1) rename the operator in XMonad.Actions.Volume, or (2) hide the operator from Prelude and tell everyone who wants to use XMonad.Actions.Volume.(<*) that they need to hide it from Prelude too. xmonad-extras is not officially a part of the xmonad project; you should contact the maintainers listed at http://hackage.haskell.org/package/xmonad-extras . -Brent On Mon, Apr 6, 2015 at 11:45 PM Dave Macias wrote: > This is my first time posting here so i hope im doing this right. > Just updated ghc to 7.10.1 and had to rebuild xmonad, xmonad-contrib, and > xmobar. > I also use xmonad-extras but it failed during the build. I tried using > cabal and also from source but both give same output: > > $ cabal install xmonad-extras > > Resolving dependencies... > Configuring xmonad-extras-0.12... > Building xmonad-extras-0.12... > Failed to install xmonad-extras-0.12 > Build log ( /home/dvmacias/.cabal/logs/xmonad-extras-0.12.log ): > Configuring xmonad-extras-0.12... > Building xmonad-extras-0.12... > Preprocessing library xmonad-extras-0.12... > [1 of 2] Compiling XMonad.Util.WindowPropertiesRE ( > XMonad/Util/WindowPropertiesRE.hs, > dist/build/XMonad/Util/WindowPropertiesRE.o ) > [2 of 2] Compiling XMonad.Actions.Volume ( XMonad/Actions/Volume.hs, > dist/build/XMonad/Actions/Volume.o ) > > XMonad/Actions/Volume.hs:173:23: > Ambiguous occurrence ?<*? > It could refer to either ?XMonad.Actions.Volume.<*?, > defined at XMonad/Actions/Volume.hs:66:4 > or ?Prelude.<*?, > imported from ?Prelude? at > XMonad/Actions/Volume.hs:15:8-28 > (and originally defined in ?GHC.Base?) > > XMonad/Actions/Volume.hs:173:43: > Ambiguous occurrence ?<*? > It could refer to either ?XMonad.Actions.Volume.<*?, > defined at XMonad/Actions/Volume.hs:66:4 > or ?Prelude.<*?, > imported from ?Prelude? at > XMonad/Actions/Volume.hs:15:8-28 > (and originally defined in ?GHC.Base?) > > XMonad/Actions/Volume.hs:200:62: > Ambiguous occurrence ?<*? > It could refer to either ?XMonad.Actions.Volume.<*?, > defined at XMonad/Actions/Volume.hs:66:4 > or ?Prelude.<*?, > imported from ?Prelude? at > XMonad/Actions/Volume.hs:15:8-28 > (and originally defined in ?GHC.Base?) > > XMonad/Actions/Volume.hs:215:32: > Ambiguous occurrence ?<*? > It could refer to either ?XMonad.Actions.Volume.<*?, > defined at XMonad/Actions/Volume.hs:66:4 > or ?Prelude.<*?, > imported from ?Prelude? at > XMonad/Actions/Volume.hs:15:8-28 > (and originally defined in ?GHC.Base?) > > XMonad/Actions/Volume.hs:225:58: > Ambiguous occurrence ?<*? > > It could refer to either ?XMonad.Actions.Volume.<*?, > defined at XMonad/Actions/Volume.hs:66:4 > or ?Prelude.<*?, > imported from ?Prelude? at > XMonad/Actions/Volume.hs:15:8-28 > (and originally defined in ?GHC.Base?) > cabal: Error: some packages failed to install: > xmonad-extras-0.12 failed during the building phase. The exception was: > ExitFailure 1 > > > I got to look at the log but it just has what i pasted above. System is > Arch 3.19.2-1-ARCH > > Any input is appreciated. > Thanks > dave > _______________________________________________ > xmonad mailing list > xmonad at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davama at gmail.com Fri Apr 10 03:55:09 2015 From: davama at gmail.com (Dave Macias) Date: Thu, 9 Apr 2015 23:55:09 -0400 Subject: [xmonad] xmonad: xmonad-extras 0.12 fails to build In-Reply-To: References: Message-ID: Thanks for responding Brent. Not very good at haskell myself. Im looking at the XMonad.Actions.Volume and there i find: infixl 1 <* (<*) :: Monad m => m a -> m b -> m a pa <* pb = pa >>= \a -> pb >> return a I'm assuming this is what you were referring to for solution (1). I've been trying to play with it but i get mixed errors when building, how do i rename? Here is the code just in case im looking at it wrong: https://hackage.haskell.org/package/xmonad-extras-0.12/src/XMonad/Actions/Volume.hs I also plan to email the maintainer, but i would like to have this work for educational purposes. Thanks, Dave On Thu, Apr 9, 2015 at 10:04 AM, Brent Yorgey wrote: > It looks like XMonad.Actions.Volume defines an operator (<*), but as of > base-4.8 an operator with that name has been added to the Prelude. The fix > would be to either (1) rename the operator in XMonad.Actions.Volume, or (2) > hide the operator from Prelude and tell everyone who wants to use > XMonad.Actions.Volume.(<*) that they need to hide it from Prelude too. > > xmonad-extras is not officially a part of the xmonad project; you should > contact the maintainers listed at > http://hackage.haskell.org/package/xmonad-extras . > > -Brent > > On Mon, Apr 6, 2015 at 11:45 PM Dave Macias wrote: > >> This is my first time posting here so i hope im doing this right. >> Just updated ghc to 7.10.1 and had to rebuild xmonad, xmonad-contrib, and >> xmobar. >> I also use xmonad-extras but it failed during the build. I tried using >> cabal and also from source but both give same output: >> >> $ cabal install xmonad-extras >> >> Resolving dependencies... >> Configuring xmonad-extras-0.12... >> Building xmonad-extras-0.12... >> Failed to install xmonad-extras-0.12 >> Build log ( /home/dvmacias/.cabal/logs/xmonad-extras-0.12.log ): >> Configuring xmonad-extras-0.12... >> Building xmonad-extras-0.12... >> Preprocessing library xmonad-extras-0.12... >> [1 of 2] Compiling XMonad.Util.WindowPropertiesRE ( >> XMonad/Util/WindowPropertiesRE.hs, >> dist/build/XMonad/Util/WindowPropertiesRE.o ) >> [2 of 2] Compiling XMonad.Actions.Volume ( XMonad/Actions/Volume.hs, >> dist/build/XMonad/Actions/Volume.o ) >> >> XMonad/Actions/Volume.hs:173:23: >> Ambiguous occurrence ?<*? >> It could refer to either ?XMonad.Actions.Volume.<*?, >> defined at XMonad/Actions/Volume.hs:66:4 >> or ?Prelude.<*?, >> imported from ?Prelude? at >> XMonad/Actions/Volume.hs:15:8-28 >> (and originally defined in ?GHC.Base?) >> >> XMonad/Actions/Volume.hs:173:43: >> Ambiguous occurrence ?<*? >> It could refer to either ?XMonad.Actions.Volume.<*?, >> defined at XMonad/Actions/Volume.hs:66:4 >> or ?Prelude.<*?, >> imported from ?Prelude? at >> XMonad/Actions/Volume.hs:15:8-28 >> (and originally defined in ?GHC.Base?) >> >> XMonad/Actions/Volume.hs:200:62: >> Ambiguous occurrence ?<*? >> It could refer to either ?XMonad.Actions.Volume.<*?, >> defined at XMonad/Actions/Volume.hs:66:4 >> or ?Prelude.<*?, >> imported from ?Prelude? at >> XMonad/Actions/Volume.hs:15:8-28 >> (and originally defined in ?GHC.Base?) >> >> XMonad/Actions/Volume.hs:215:32: >> Ambiguous occurrence ?<*? >> It could refer to either ?XMonad.Actions.Volume.<*?, >> defined at XMonad/Actions/Volume.hs:66:4 >> or ?Prelude.<*?, >> imported from ?Prelude? at >> XMonad/Actions/Volume.hs:15:8-28 >> (and originally defined in ?GHC.Base?) >> >> XMonad/Actions/Volume.hs:225:58: >> Ambiguous occurrence ?<*? >> >> It could refer to either ?XMonad.Actions.Volume.<*?, >> defined at XMonad/Actions/Volume.hs:66:4 >> or ?Prelude.<*?, >> imported from ?Prelude? at >> XMonad/Actions/Volume.hs:15:8-28 >> (and originally defined in ?GHC.Base?) >> cabal: Error: some packages failed to install: >> xmonad-extras-0.12 failed during the building phase. The exception was: >> ExitFailure 1 >> >> >> I got to look at the log but it just has what i pasted above. System is >> Arch 3.19.2-1-ARCH >> >> Any input is appreciated. >> Thanks >> dave >> _______________________________________________ >> xmonad mailing list >> xmonad at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From c.lopez at kmels.net Fri Apr 10 04:16:00 2015 From: c.lopez at kmels.net (=?UTF-8?Q?Carlos_L=C3=B3pez=2DCamey?=) Date: Thu, 9 Apr 2015 22:16:00 -0600 Subject: [xmonad] xmonad: xmonad-extras 0.12 fails to build In-Reply-To: References: Message-ID: Hi Dave, by the results of hoogle *, it looks like (<*) is defined in Applicative. I think Applicative is a super class of Monad in newer GHC and is now included in the Prelude. So, I believe it would be safe to just remove it. * https://www.haskell.org/hoogle/?hoogle=Monad+m+%3D%3E+m+a+-%3E+m+b+-%3E+m+a Cheers 2015-04-09 21:55 GMT-06:00 Dave Macias : > Thanks for responding Brent. > > Not very good at haskell myself. > Im looking at the XMonad.Actions.Volume and there i find: > > infixl 1 <* > (<*) :: Monad m => m a -> m b -> m a > pa <* pb = pa >>= \a -> pb >> return a > > I'm assuming this is what you were referring to for solution (1). I've > been trying to play with it but i get mixed errors when building, how do i > rename? > Here is the code just in case im looking at it wrong: > > https://hackage.haskell.org/package/xmonad-extras-0.12/src/XMonad/Actions/Volume.hs > > I also plan to email the maintainer, but i would like to have this work > for educational purposes. > > Thanks, > Dave > > On Thu, Apr 9, 2015 at 10:04 AM, Brent Yorgey wrote: > >> It looks like XMonad.Actions.Volume defines an operator (<*), but as of >> base-4.8 an operator with that name has been added to the Prelude. The fix >> would be to either (1) rename the operator in XMonad.Actions.Volume, or (2) >> hide the operator from Prelude and tell everyone who wants to use >> XMonad.Actions.Volume.(<*) that they need to hide it from Prelude too. >> >> xmonad-extras is not officially a part of the xmonad project; you should >> contact the maintainers listed at >> http://hackage.haskell.org/package/xmonad-extras . >> >> -Brent >> >> On Mon, Apr 6, 2015 at 11:45 PM Dave Macias wrote: >> >>> This is my first time posting here so i hope im doing this right. >>> Just updated ghc to 7.10.1 and had to rebuild xmonad, xmonad-contrib, >>> and xmobar. >>> I also use xmonad-extras but it failed during the build. I tried using >>> cabal and also from source but both give same output: >>> >>> $ cabal install xmonad-extras >>> >>> Resolving dependencies... >>> Configuring xmonad-extras-0.12... >>> Building xmonad-extras-0.12... >>> Failed to install xmonad-extras-0.12 >>> Build log ( /home/dvmacias/.cabal/logs/xmonad-extras-0.12.log ): >>> Configuring xmonad-extras-0.12... >>> Building xmonad-extras-0.12... >>> Preprocessing library xmonad-extras-0.12... >>> [1 of 2] Compiling XMonad.Util.WindowPropertiesRE ( >>> XMonad/Util/WindowPropertiesRE.hs, >>> dist/build/XMonad/Util/WindowPropertiesRE.o ) >>> [2 of 2] Compiling XMonad.Actions.Volume ( XMonad/Actions/Volume.hs, >>> dist/build/XMonad/Actions/Volume.o ) >>> >>> XMonad/Actions/Volume.hs:173:23: >>> Ambiguous occurrence ?<*? >>> It could refer to either ?XMonad.Actions.Volume.<*?, >>> defined at XMonad/Actions/Volume.hs:66:4 >>> or ?Prelude.<*?, >>> imported from ?Prelude? at >>> XMonad/Actions/Volume.hs:15:8-28 >>> (and originally defined in ?GHC.Base?) >>> >>> XMonad/Actions/Volume.hs:173:43: >>> Ambiguous occurrence ?<*? >>> It could refer to either ?XMonad.Actions.Volume.<*?, >>> defined at XMonad/Actions/Volume.hs:66:4 >>> or ?Prelude.<*?, >>> imported from ?Prelude? at >>> XMonad/Actions/Volume.hs:15:8-28 >>> (and originally defined in ?GHC.Base?) >>> >>> XMonad/Actions/Volume.hs:200:62: >>> Ambiguous occurrence ?<*? >>> It could refer to either ?XMonad.Actions.Volume.<*?, >>> defined at XMonad/Actions/Volume.hs:66:4 >>> or ?Prelude.<*?, >>> imported from ?Prelude? at >>> XMonad/Actions/Volume.hs:15:8-28 >>> (and originally defined in ?GHC.Base?) >>> >>> XMonad/Actions/Volume.hs:215:32: >>> Ambiguous occurrence ?<*? >>> It could refer to either ?XMonad.Actions.Volume.<*?, >>> defined at XMonad/Actions/Volume.hs:66:4 >>> or ?Prelude.<*?, >>> imported from ?Prelude? at >>> XMonad/Actions/Volume.hs:15:8-28 >>> (and originally defined in ?GHC.Base?) >>> >>> XMonad/Actions/Volume.hs:225:58: >>> Ambiguous occurrence ?<*? >>> >>> It could refer to either ?XMonad.Actions.Volume.<*?, >>> defined at XMonad/Actions/Volume.hs:66:4 >>> or ?Prelude.<*?, >>> imported from ?Prelude? at >>> XMonad/Actions/Volume.hs:15:8-28 >>> (and originally defined in ?GHC.Base?) >>> cabal: Error: some packages failed to install: >>> xmonad-extras-0.12 failed during the building phase. The exception was: >>> ExitFailure 1 >>> >>> >>> I got to look at the log but it just has what i pasted above. System is >>> Arch 3.19.2-1-ARCH >>> >>> Any input is appreciated. >>> Thanks >>> dave >>> _______________________________________________ >>> xmonad mailing list >>> xmonad at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad >>> >> > > _______________________________________________ > xmonad mailing list > xmonad at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vogt.adam at gmail.com Fri Apr 10 04:35:41 2015 From: vogt.adam at gmail.com (adam vogt) Date: Fri, 10 Apr 2015 00:35:41 -0400 Subject: [xmonad] xmonad: xmonad-extras 0.12 fails to build In-Reply-To: References: Message-ID: Hi. The fixity is different (infixl 1 not infixl 4) so using the one from control.applicative means some parentheses have to be added. Regards, Assam On Apr 10, 2015 12:16 AM, "Carlos L?pez-Camey" wrote: > Hi Dave, by the results of hoogle *, it looks like (<*) is defined in > Applicative. I think Applicative is a super class of Monad in newer GHC and > is now included in the Prelude. So, I believe it would be safe to just > remove it. > > * > https://www.haskell.org/hoogle/?hoogle=Monad+m+%3D%3E+m+a+-%3E+m+b+-%3E+m+a > > Cheers > > 2015-04-09 21:55 GMT-06:00 Dave Macias : > >> Thanks for responding Brent. >> >> Not very good at haskell myself. >> Im looking at the XMonad.Actions.Volume and there i find: >> >> infixl 1 <* >> (<*) :: Monad m => m a -> m b -> m a >> pa <* pb = pa >>= \a -> pb >> return a >> >> I'm assuming this is what you were referring to for solution (1). I've >> been trying to play with it but i get mixed errors when building, how do i >> rename? >> Here is the code just in case im looking at it wrong: >> >> https://hackage.haskell.org/package/xmonad-extras-0.12/src/XMonad/Actions/Volume.hs >> >> I also plan to email the maintainer, but i would like to have this work >> for educational purposes. >> >> Thanks, >> Dave >> >> On Thu, Apr 9, 2015 at 10:04 AM, Brent Yorgey wrote: >> >>> It looks like XMonad.Actions.Volume defines an operator (<*), but as of >>> base-4.8 an operator with that name has been added to the Prelude. The fix >>> would be to either (1) rename the operator in XMonad.Actions.Volume, or (2) >>> hide the operator from Prelude and tell everyone who wants to use >>> XMonad.Actions.Volume.(<*) that they need to hide it from Prelude too. >>> >>> xmonad-extras is not officially a part of the xmonad project; you should >>> contact the maintainers listed at >>> http://hackage.haskell.org/package/xmonad-extras . >>> >>> -Brent >>> >>> On Mon, Apr 6, 2015 at 11:45 PM Dave Macias wrote: >>> >>>> This is my first time posting here so i hope im doing this right. >>>> Just updated ghc to 7.10.1 and had to rebuild xmonad, xmonad-contrib, >>>> and xmobar. >>>> I also use xmonad-extras but it failed during the build. I tried using >>>> cabal and also from source but both give same output: >>>> >>>> $ cabal install xmonad-extras >>>> >>>> Resolving dependencies... >>>> Configuring xmonad-extras-0.12... >>>> Building xmonad-extras-0.12... >>>> Failed to install xmonad-extras-0.12 >>>> Build log ( /home/dvmacias/.cabal/logs/xmonad-extras-0.12.log ): >>>> Configuring xmonad-extras-0.12... >>>> Building xmonad-extras-0.12... >>>> Preprocessing library xmonad-extras-0.12... >>>> [1 of 2] Compiling XMonad.Util.WindowPropertiesRE ( >>>> XMonad/Util/WindowPropertiesRE.hs, >>>> dist/build/XMonad/Util/WindowPropertiesRE.o ) >>>> [2 of 2] Compiling XMonad.Actions.Volume ( XMonad/Actions/Volume.hs, >>>> dist/build/XMonad/Actions/Volume.o ) >>>> >>>> XMonad/Actions/Volume.hs:173:23: >>>> Ambiguous occurrence ?<*? >>>> It could refer to either ?XMonad.Actions.Volume.<*?, >>>> defined at XMonad/Actions/Volume.hs:66:4 >>>> or ?Prelude.<*?, >>>> imported from ?Prelude? at >>>> XMonad/Actions/Volume.hs:15:8-28 >>>> (and originally defined in ?GHC.Base?) >>>> >>>> XMonad/Actions/Volume.hs:173:43: >>>> Ambiguous occurrence ?<*? >>>> It could refer to either ?XMonad.Actions.Volume.<*?, >>>> defined at XMonad/Actions/Volume.hs:66:4 >>>> or ?Prelude.<*?, >>>> imported from ?Prelude? at >>>> XMonad/Actions/Volume.hs:15:8-28 >>>> (and originally defined in ?GHC.Base?) >>>> >>>> XMonad/Actions/Volume.hs:200:62: >>>> Ambiguous occurrence ?<*? >>>> It could refer to either ?XMonad.Actions.Volume.<*?, >>>> defined at XMonad/Actions/Volume.hs:66:4 >>>> or ?Prelude.<*?, >>>> imported from ?Prelude? at >>>> XMonad/Actions/Volume.hs:15:8-28 >>>> (and originally defined in ?GHC.Base?) >>>> >>>> XMonad/Actions/Volume.hs:215:32: >>>> Ambiguous occurrence ?<*? >>>> It could refer to either ?XMonad.Actions.Volume.<*?, >>>> defined at XMonad/Actions/Volume.hs:66:4 >>>> or ?Prelude.<*?, >>>> imported from ?Prelude? at >>>> XMonad/Actions/Volume.hs:15:8-28 >>>> (and originally defined in ?GHC.Base?) >>>> >>>> XMonad/Actions/Volume.hs:225:58: >>>> Ambiguous occurrence ?<*? >>>> >>>> It could refer to either ?XMonad.Actions.Volume.<*?, >>>> defined at XMonad/Actions/Volume.hs:66:4 >>>> or ?Prelude.<*?, >>>> imported from ?Prelude? at >>>> XMonad/Actions/Volume.hs:15:8-28 >>>> (and originally defined in ?GHC.Base?) >>>> cabal: Error: some packages failed to install: >>>> xmonad-extras-0.12 failed during the building phase. The exception was: >>>> ExitFailure 1 >>>> >>>> >>>> I got to look at the log but it just has what i pasted above. System is >>>> Arch 3.19.2-1-ARCH >>>> >>>> Any input is appreciated. >>>> Thanks >>>> dave >>>> _______________________________________________ >>>> xmonad mailing list >>>> xmonad at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad >>>> >>> >> >> _______________________________________________ >> xmonad mailing list >> xmonad at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad >> >> > > _______________________________________________ > xmonad mailing list > xmonad at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Fri Apr 10 19:40:07 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Fri, 10 Apr 2015 15:40:07 -0400 Subject: [xmonad] [patch] Dynamic window property matching Message-ID: 1 patch for repository http://code.haskell.org/XMonadContrib: Fri Apr 10 15:34:49 EDT 2015 allbery.b at gmail.com * dynamicproperty Run a ManageHook from handleEventHook when a window property changes. You would use this to match e.g. browser windows whose title is not "final" until after the on-load hooks of the loaded document complete. New patches: [dynamicproperty allbery.b at gmail.com**20150410193449 Ignore-this: 7f58cbd7fadeffa96a3b635d14a51d4b Run a ManageHook from handleEventHook when a window property changes. You would use this to match e.g. browser windows whose title is not "final" until after the on-load hooks of the loaded document complete. ] { addfile ./XMonad/Hooks/DynamicProperty.hs hunk ./XMonad/Hooks/DynamicProperty.hs 1 +----------------------------------------------------------------------------- +-- | +-- Module : XMonad.Hooks.DynamicProperty +-- Copyright : (c) Brandon S Allbery, 2014 +-- License : BSD3-style (see LICENSE) +-- +-- Maintainer : allbery.b at gmail.com +-- Stability : unstable +-- Portability : not portable +-- +-- Module to apply a ManageHook to an already-mapped window when a property +-- changes. This would commonly be used to match browser windows by title, +-- since the final title will only be set after (a) the window is mapped, +-- (b) its document has been loaded, (c) all load-time scripts have run. +-- (Don't blame browsers for this; it's inherent in HTML and the DOM. And +-- changing title dynamically is explicitly permitted by ICCCM and EWMH; +-- you don't really want to have your editor window umapped/remapped to +-- show the current document and modified state in the titlebar, do you?) +-- +-- This is a handleEventHook that triggers on a PropertyChange event. It +-- currently ignores properties being removed, in part because you can't +-- do anything useful in a ManageHook involving nonexistence of a property. +-- +----------------------------------------------------------------------------- + +module XMonad.Hooks.DynamicProperty where + +import XMonad +import Data.Monoid +import Control.Applicative +import Control.Monad (when) + +-- | +-- Run a 'ManageHook' when a specific property is changed on a window. Note +-- that this will run on any window which changes the property, so you should +-- be very specific in your 'MansgeHook' matching (lots of windows change +-- their titles on the fly!): +-- +-- dynamicPropertyChange "WM_NAME" (className =? "Iceweasel" <&&> title =? "whatever" --> doShift "2") +-- +-- Note that the fixity of (-->) won't allow it to be mixed with ($), so you +-- can't use the obvious $ shorthand. +-- +-- > dynamicPropertyChange "WM_NAME" $ title =? "Foo" --> doFloat -- won't work! +-- +-- Consider instead phrasing it like any +-- other 'ManageHook': +-- +-- > , handleEventHook = dynamicPropertyChange "WM_NAME" myDynHook <+> handleEventHook baseConfig +-- > +-- > {- ... -} +-- > +-- > myDynHook = composeAll [...] +-- +dynamicPropertyChange :: String -> ManageHook -> Event -> X All +dynamicPropertyChange prop hook PropertyEvent { ev_window = w, ev_atom = a, ev_propstate = ps } = do + pa <- getAtom prop + when (ps == propertyNewValue && a == pa) $ do + g <- appEndo <$> userCodeDef (Endo id) (runQuery hook w) + windows g + return (All False) -- so anything else also processes it + +-- | A shorthand for the most common case, dynamic titles +dynamicTitle :: ManageHook -> Event -> X All +-- strictly, this should also check _NET_WM_NAME. practically, both will +-- change and each gets its own PropertyEvent, so we'd need to record that +-- we saw the event for that window and ignore the second one. Instead, just +-- trust that nobody sets only _NET_WM_NAME. (I'm sure this will prove false, +-- since there's always someone who can't bother being compliant.) +dynamicTitle = dynamicPropertyChange "WM_NAME" hunk ./xmonad-contrib.cabal 167 XMonad.Hooks.DynamicBars XMonad.Hooks.DynamicHooks XMonad.Hooks.DynamicLog + XMonad.Hooks.DynamicProperty XMonad.Hooks.DebugStack XMonad.Hooks.EwmhDesktops XMonad.Hooks.FadeInactive } Context: [minor doc fixes to X.C.Mate Daniel Wagner **20150330180752 Ignore-this: f35c2e5068adcf5a04727557078c8a6f ] [mate-comment-fixup allbery.b at gmail.com**20150330160523 Ignore-this: 687b5edc9220469f3e58abcfd4f6449c Correct the docstrings / comments in X.C.Mate, which still referenced gnomeConfig. Also update the session manager configuration to use dconf and a current (on Mint at least) path for the session config. ] [Add the ability to specify padding used with Maximize Peter Jones **20150309232939 Ignore-this: 71ac5db4513da0b7a45eb82ec184f4e3 ] [Don't restore windows when changing workspaces Peter Jones **20150310201709 Ignore-this: 5333205aa1a9fbc5c7844fad69561517 ] [New layout modifier: Hidden Peter Jones **20150309223036 Ignore-this: 5534fe18e642d1691a9b3f99341e082d A layout modifer that is meant to work with the BinarySpacePartition layout. By removing windows from the window set and adding them back at a later time, you can move windows to a different branch of the BSP tree. ] [Fixes to warnings with BSP layout anton.pirogov at gmail.com**20150315100041 Ignore-this: 7642710fdb2a866150875f2d521d19fd ] [Improved BinarySpacePartition, added Equalize,Balance and FocusParent and mouse resize support anton.pirogov at gmail.com**20150312145220 Ignore-this: 31b5d7bf38e5b391df266906deb5e382 ] [New layout module X.L.Dwindle nzeh at cs.dal.ca**20150315130913 Ignore-this: a1507e9eda6e6cabd679c2c3b50d9a38 This adds three layouts: Spiral is a reimplementation of X.L.Spiral.spiral with a (to me) more intuitive splitting policy. Dwindle is similar but pushes the smaller windows into a corner rather than into the center. Squeeze just stacks windows vertically or horizontally using geometrically decreasing sizes. ] [address warnings in P.Pass Adam Vogt **20150313015636 Ignore-this: 52e03c09c4d5339085e0306044de8977 ] [X.L.AvoidFloats more useful default settings ankaan at gmail.com**20150310212022 Ignore-this: af6535bace9219619858751eeeff6520 Changed default settings with the simple layout modifier. Instead of asking for a bool indicating if all windows should be avoided, no such bool is asked for. No windows are avoided by default. I think this will be a more useful default setting since it would be annoying if dialogue windows are avoided. The same functionality is possible with the advanced constructor. This will be easier for new users. This will break configurations using the old module, but this will not be much of an issue since the module has not been added to the repo as of this writing. ] [Resolve minor conflict in xmonad-contrib.cabal ankaan at gmail.com**20150306175436 Ignore-this: 24ae68c08107a574199b055989d38347 ] [X.L.AvoidFloats, like avoidStruts but for floats ankaan at gmail.com**20150306171702 Ignore-this: 3722d7787dd2429313f92f85f3ae1251 Checks for floating windows within the layout area and finds a maximum area rectangle within that does not overlap with any of the floating windows. This rectangle is used for all non-floating windows. This new functionality introduced problems with the recommended configuration of one of my other modules (X.A.FloatSnap.) A new and more reliable method of distinguishing between clicks and drags where therefore introduced in the new module X.A.AfterDrag. This does not break any prior use of FloatSnap, but will require changes in configuration if used together with AvoidFloats. (This is mentioned in the docs for AvoidFloats and I recommend using the new configuration method even if AvoidFloats is not in use.) ] [X.L.LayoutBuilder place active on top ankaan at gmail.com**20150306164200 Ignore-this: 69d718d0d044ee59a877fa0e63edc474 Make sure that the active layout area is placed on top of all other areas when placing windows. This makes overlapping areas usable. ] [Add rearrangers to X.A.GridSelect Dmitri Iouchtchenko **20130123044038 Ignore-this: ef0dc68e9b725953e69e7b039fe06e9a ] [Avoid repainting elements in X.A.GridSelect Dmitri Iouchtchenko **20130123043850 Ignore-this: 8e926cebc8d458a06a05f7457ae40b68 ] [Give a name to the initial state in X.A.GridSelect Dmitri Iouchtchenko **20130121061324 Ignore-this: 989ae20ccc3d5b1392f0694d5c62e759 ] [Add XMonad.Config.Bepo (Yorick Laupa) Adam Vogt **20150310214314 Ignore-this: 71dcf03f9ff80b645531004f95e9c600 ] [add instance Default WallpaperConf Adam Vogt **20150310214246 Ignore-this: 18e74f249b35726acd4b923ecce3085 ] [XMonad.Prompt.Pass: Handle hierachical password stores Joachim Breitner **20150218091816 Ignore-this: 2f0a02613780067d324b04a8cdb9c0ed pass stores its passwords in directories, so the contents of the directory store needs to be enumerated recursively. Alexander Sulfrian provided this patch on the mailinglist, which I tested (it works) and cleaned up slightly. ] [remove warnings and text dependency from H.WallpaperSetter Adam Vogt **20150310192933 Ignore-this: e637d782c13bed48bafbc1458b3f983f ] [Added the new hook WallpaperSetter anton.pirogov at gmail.com**20150228162335 Ignore-this: 7cbb2ab0d8f9f606f50253deebcf4163 ] [adjust an import to fix the build Adam Vogt **20150310182403 Ignore-this: 72f67dd2cb1cc6900269383124844c2b ] [merge conflicts in X.L.Spacing Adam Vogt **20150310182046 Ignore-this: f0830d6483d30d643e7e182e310ec042 I should have just applied Anton Pirogov March 4 patch. ] [Added messages to adjust the gap dynamically anton.pirogov at gmail.com**20150304082520 Ignore-this: 52b590c820db765796de41f38fffdf3c ] [X.L.Spacing needs -XPatternGuards now Adam Vogt **20150310181248 Ignore-this: d6b2b76fddbd9ad066e7cb39933f055a ] [add ConfirmPrompt (Antoine Beaupr?) Adam Vogt **20150310181036 Ignore-this: 65d74f05e82c66a3ff4f021d19ceb626 ] [Added messages to adjust the gap dynamically anton.pirogov at gmail.com**20150303210143 Ignore-this: 891ca1ccca183d6af8e4aa4bf6d843fb ] [add another extension to actually fix the build with ghc-7.10-RC1 Adam Vogt **20150124111939 Ignore-this: 26d6f1b4cb6d573ccf49e6baeca853e4 ] [BinarySpacePartition downstream changes benweitzman at gmail.com**20141110202259 Ignore-this: 42ecc2b07388ba0c7b3eac980256c17b Pulled in changes from my repo for this layout on github ( https://github.com/benweitzman/BinarySpacePartition) Includes a new mode for resizing windows in a more intuitive way, also contains a bug fix that was preventing users from resiving a window up. Includes changes from github users egasimus (Adam Avramov) and SolitaryCipher (Nick) ] [add XF86AudioMicMute to EZConfig (#582) Adam Vogt **20141222045306 Ignore-this: 1c91505b303e53b94da624230b3c893c ] [Generalize new workspace addition functions to support arbitrary insertion. nrujac at gmail.com**20141219002309 Ignore-this: 9f8c14b5aa9d398b3f167da0af1a8650 The current DynamicWorkspaces module only supports adding new workspaces at the start of the list of workspaces. This means when binding workspaces to keys based on the position in the list, key bindings can change as workspaces are added in removed in a far more destructive way than necessary. Instead, supporting appending and arbitrary insertion allows the user to determine where the new workspace should be added. This patch is a straight generalization of the addHiddenWorkspace' function. Rather than always using `(:)` to insert the new workspace into the list of workspaces, this patches causes it to use an arbitrary list insertion function instead. A few new functions are added to prevent breakage of external code while exported functions are left unchanged. List of new functions: appendWorkspace appendWorkspacePrompt addWorkspaceAt addHiddenWorkspaceAt Existing functions were modified to call their generalized brethren where possible without changing functionality. This patch should not change behavior for any existing users of this module. ] [address another bitSize/finiteBitSize warning Adam Vogt **20141222033300 Ignore-this: 549e519d25080c77e605dc983f0d239e ] [X.L.Master: Add FixMaster layout modifier Anton Vorontsov **20141220011339 Ignore-this: 82e9736853287f753248af41843ceb6b This layout modifier is useful for the case if you desire to add a master pane that has fixed width (it's fixed even if there is just one window opened). Especially nice feature if you don't want to have too wide terminal in a master pane. The layout is implemented as an addition to Master layout, so it reuses most of the code. ] [filepath dependency for P.Pass was left out Adam Vogt **20141221214129 Ignore-this: 98e63d7b17ac6ebabd8a6b081f5194a1 ] [remove unused imports Adam Vogt **20140815051234 Ignore-this: b2e5be31b70e6d31827e76bd8c00d200 ] [fix build with ghc-6.12 Adam Vogt **20140815051214 Ignore-this: d4c4da527db6c8affc151dc210631b85 ] [use FiniteBitSize with ghc >= 7.8 Adam Vogt **20140815051136 Ignore-this: 90f855fd72406fb3d2640a133d499188 ] [Layout.Spacing: Outer window edges now get as much spacing as inner ones Felix Crux **20141219223646 Ignore-this: 61363e97939fe857876c8252ac5f0302 Layout.Spacing applies a customizable amount of space around the outside of each window. At window edges where two windows meet, the total distance between them is therefore twice the customized value (one space value from each window). At the edge of the screen, however, the spacing is only applied once. This results in uneven amounts of spacing and differently-sized gaps on the screen. This patch extends the Spacing layout to include a further gap all around the edge of the screen, thus making all spaces around windows equal in size. ] [add filepath package dependency needed by Prompt.Pass Adam Vogt **20140909145216 Ignore-this: 588ec76e7fccb4219361da7024c98db4 filepath comes with ghc, and it's used by xmonad-core anyways ] [X.C.Prime: doc tweaks Devin Mullins **20141002075939 Ignore-this: 20d6b829b810f48b5e4b4c161b39b312 ] [X.A.Navigation2D: add convenience functions for setting config & keybindings Devin Mullins **20141002075757 Ignore-this: ed01137f03a531f73315ed503d1eb6ef 1. Added 'additionalNav2DKeys' which adds keybindings for the cartesian product of direction keys and (modifier, action) pairs given. 2. Added 'navigation2D' which combines that with 'withNavigation2DConfig'. 3. Added 'additionalNav2DKeysP' and 'navigation2DP' which do the same, but use the 'additionalKeysP' syntax. ] [X.C.Prime: doc fixes Devin Mullins **20141001075855 Ignore-this: dbbe00791b04df61dcd595c50333fba ] [X.C.Prime: add 'withScreens' and friends Devin Mullins **20141001075250 Ignore-this: eba37b1ff3da265a4dcc509f538fce4d The screen equivalent of 'withWorkspaces' lets you more easily define keys that move/swap between screens. Also, rename wsKeyspecs to wsKeys, and make a couple of doc tweaks. ] [Implement proper handling of dynamically changing hostname Anton Vorontsov **20140901072158 Ignore-this: 2aeac6d2161e666d40cda6a09f78b208 The module implements a proper way of finding out whether the window is remote or local. Just checking for a hostname and WM_CLIENT_MACHINE being equal is often not enough because the hostname is a changing subject (without any established notification mechanisms), and thus WM_CLIENT_MACHINE and the hostname can diverge even for a local window. This module solves the problem. As soon as there is a new window created, we check the hostname and WM_CLIENT_MACHINE, and then we cache the result into the XMONAD_REMOTE property. Notice that XMonad itself does not know anything about hostnames, nor does it have any dependency on Network.* modules. For this module it is not a problem: you can provide a mean to get the hostname through your config file (see usage). Or, if you don't like the hassle of handling dynamic hostnames (suppose your hostname never changes), it is also fine: this module will fallback to using environment variables. ] [Add Stoppable layout for power saving Anton Vorontsov **20140901072141 Ignore-this: a52805d9f3095cd7af48507847ed2fe3 This module implements a special kind of layout modifier, which when applied to a layout, causes xmonad to stop all non-visible processes. In a way, this is a sledge-hammer for applications that drain power. For example, given a web browser on a stoppable workspace, once the workspace is hidden the web browser will be stopped. Note that the stopped application won't be able to communicate with X11 clipboard. For this, the module actually stops applications after a certain delay, giving a chance for a user to complete copy-paste sequence. By default, the delay equals to 15 seconds, it is configurable via 'Stoppable' constructor. The stoppable modifier prepends a mark (by default equals to "Stoppable") to the layout description (alternatively, you can choose your own mark and use it with 'Stoppable' constructor). The stoppable layout (identified by a mark) spans to multiple workspaces, letting you to create groups of stoppable workspaces that only stop processes when none of the workspaces are visible, and conversely, unfreezing all processes even if one of the stoppable workspaces are visible. To stop the process we use signals, which works for most cases. For processes that tinker with signal handling (debuggers), another (Linux-centric) approach may be used. See https://www.kernel.org/doc/Documentation/cgroups/freezer-subsystem.txt ] [X.C.Prime: doc changes Devin Mullins **20140925203037 Ignore-this: 51204c1a9f2e6ed21228d2910417fd21 ] [X.C.Prime: add withWorkspaces et al. Devin Mullins **20140925203034 Ignore-this: 65f691270110cc5de13c950d9dcb0c17 This allows easier configuration of workspaces and their keybindings. Required generalizing the 'Prime' type, so lots of other lines changed in rather trivial ways. ] [X.C.Prime: add ifThenElse binding Devin Mullins **20140924191509 Ignore-this: ae775c418c27301b9c12d2a233502cec This is necessary for if-then-else support in the user's config. ] [X.C.Prime: doc fixes Devin Mullins **20140915080601 Ignore-this: 15e3c445a99d3b2d3a235aa76119797 ] [X.C.Prime: fix 'def' hyperlink in doc Devin Mullins **20140914075352 Ignore-this: a1de1d81a5f140ab7d90edbf393e9bda ] [XMonad.Config.Prime, a do-notation for config Devin Mullins **20140914064828 Ignore-this: f7397aa6e6efe5d76acebfa22c567baa Note that the use of RebindableSyntax is because of the need to vary the layoutHook type throughout the config. The alternative, using the existential Layout type, was rejected because it required TemplateHaskell in order to look nice, and TemplateHaskell is not portable. I've tried to make a version of (>>) that also worked on normal monads, but have had no luck as of yet. Maybe some intrepid soul can add it later. ] [X.P.Shell: fix doc typo me at twifkak.com**20130317115516 Ignore-this: bdd385a9142ed039a917d135e76293fe ] [reverse workspaces, so that switching to a dynamic workspace group restores the focus to the screen that was focused at group creation time nwfilardo at gmail.com**20140913174118 Ignore-this: b74c02b1892159694827e35122c2d517 ] [add filepath dependency, needed by new X.P.Pass module me at twifkak.com**20140913070926 Ignore-this: fec97086c1e66cf8a036265bd1a970a8 ] [add-new-xmonad-prompt-pass eniotna.t at gmail.com**20140829131928 Ignore-this: 11e85dfe3d24cef88d8d89f4e7b1ec0b This module provides 3 to ease passwords manipulation (generate, read, remove): - one to lookup passwords in the password-storage. - one to generate a password for a given password label that the user inputs. - one to delete a stored password for a given password label that the user inputs. All those prompts benefit from the completion system provided by the module . The password store is setuped through an environment variable PASSWORD_STORE_DIR. If this is set, use the content of the variable. Otherwise, the password store is located on user's home @$HOME\/.password-store at . Source: - The password storage implementation is < http://git.zx2c4.com/password-store the password-store cli>. - Inspired from ] [use Data.Map instead of Data.Map.Strict to support containers < 0.5 Adam Vogt **20140815043141 Ignore-this: 436d18657d8499f4ce57311e84503d9f ] [config-mate allbery.b at gmail.com**20140803020659 Ignore-this: d5de258c0a28cd5ba64a59cf37cd480a Initial support for the Mate desktop environment (http://mate-desktop.org). Based on existing Gnome 2 support, since Mate is a maintained fork of Gnome 2. ] [debug-managehook allbery.b at gmail.com**20140803020601 Ignore-this: 51f9255b496cca79e4a53e274c400ecc A set of hooks, and convenience combinators, to help with ManageHook debugging. Ordinary users may well want to use debugManageHookOn in normal configs, specifying a key sequence which can be pressed before running a command in order to capture debug information just for that command's main window. This is especially useful when trying to diagnose issues such as programs that do not play well with SpawnOn, or ManageHook matching on 'title' when the program does not set the window title until after it is mapped. ] [debug-debug allbery.b at gmail.com**20140803020530 Ignore-this: cbb2b1d99293e3a4d02a256c2733aeb0 Various fixes and enhancements to DebugWindow and DebugStack. ManageDebug requires these fixes, but some of them are significant even if not using ManageDebug. ] [derive Applicative instances to suppress AMP warning Adam Vogt **20140710163950 Ignore-this: c2110d07bccc61462c3fbf73c900aaa1 ] [clean up cabal file and drop support for base < 3 Adam Vogt **20140710013255 Ignore-this: 76b142e2b114604feac9b8e41cf71ab ] [add-duck-duck-go-search-engine eniotna.t at gmail.com**20140617174246 Ignore-this: 29bbfb2d07d9ddf36bf0268a4e255f81 ] [XSelection: getSelection: fix connection exhaustion bug (issue #573); include warning gwern at gwern.net**20140601025019 Ignore-this: add21190fc07338b243c2241cc746119 ] [Fix dbus-send call in XMonad.Config.Gnome md143rbh7f at gmail.com**20140129032114 Ignore-this: ed62458b55c8b34b77f73027eeee1a73 dbus-send --print-reply=string is invalid, but it was silently ignored until recently: http://cgit.freedesktop.org/dbus/dbus/commit/tools/dbus-send.c?id=c690ee4351f99ed5e629ffcf5f4a2edcd418d103 I've changed XMonad.Config.Gnome to run --print-reply=literal, since that's what the old behavior was. ] [warning police (unused variables) Adam Vogt **20140505001242 Ignore-this: a15b4d844b1da4f1f1f9b6095c968705 ] [This patch makes the Ssh extension works with **user** arguments in ssh, .e.g ssh admin at localhost. linxray at gmail.com**20140504091120 Ignore-this: 297673e11d3049c4f127aac3e172d361 ] [remove trailing whitespace in L.BinarySpacePartition Adam Vogt **20140501011943 Ignore-this: 8dd677978992e0854801b8f254463dc2 ] [replace Bound with the equivalent Direction2D Adam Vogt **20140501011540 Ignore-this: b1f1c256aba07f70918fe1d693c8087b ] [remove unused extension in BSP Adam Vogt **20140501011455 Ignore-this: a4962486b2aa3980536bff19a537451e ] [Add BinarySpacePartition layout benweitzman at gmail.com**20140430205848 Ignore-this: a85d1dc51bf54c59ae2bd9d948cc1088 ] [X.Actions.DynamicWorkspaceGroups: export new function addRawWSGroup Brent Yorgey **20140428142901 Ignore-this: a487882c9571bf91ff921d6561bb4cc6 ] [Remove unneeded context with the IfMax layout instance Adam Vogt **20140422221105 Ignore-this: 3b8ac316f56df6a84420754db769fb0 Extra constraints on instances are about as useful as -XDataTypeContexts ] [Adding side tabs and replacing TabbarLocation with Direction2D. nrujac at gmail.com**20140219200811 Ignore-this: edabeec973b4e0d61515818367689843 ] [warning police Daniel Wagner **20140316183747 Ignore-this: fd16435ccdd3fee8924723cc690cc239 ] [New module: XMonad.Util.WindowState Dmitry Bogatov **20140218100229 Ignore-this: 14a6fa263c423cd8cca3b2645b3930d7 Save almost arbitary data per window ] [Add side tabs to the tabbed layout. nrujac at gmail.com**20140213215247 Ignore-this: f81bafe9cb75a30ed6bbbe68cf5d66c0 ] [SpawnNamedPipe hlint cleanup cwills.dev at gmail.com**20140202213613 Ignore-this: dbb68c4c5522026bd108d0158e747b48 ] [document and cleanup SpawnNamedPipe cwills.dev at gmail.com**20140202211000 Ignore-this: b264278f1f1ab1f18b37245a5ff33136 ] [Added SpawnNamedPipe cwills.dev at gmail.com**20140202143415 Ignore-this: 87797ffffc8d0fd088482bd0c5baf0e ] [Make commandToComplete in XMonad.Prompt.Shell complete last word md143rbh7f at gmail.com**20140130200050 Ignore-this: b0fe22fdd7b9409835fd0ca069f2e01a The following change from 2013-02-09 breaks shell completion for me: hunk ./XMonad/Prompt/Shell.hs 65 + commandToComplete _ c = c It seems to be passing the entire string into compgen in order to get the file completions, but it should only pass the last word. I propose reverting this change. Comments are appreciated. ] [expose and document X.L.IndependentScreens.marshallSort Daniel Wagner **20140128212844 Ignore-this: 90c1437c6ffe1dbd8f4a4ed192097ec ] [ServerMode properly indent Adam Vogt **20131219201440 Ignore-this: 761b39c3e3c90b6123f068e8b1d34e5d ] [remove ServerMode tabs Adam Vogt **20131219201000 Ignore-this: f21448c248ec0ac289c309ed964ebcff ] [fix -Wall ServerMode Adam Vogt **20131219181030 Ignore-this: 708dd5fc60f43dee3d1da085002052f ] [documentation note that ServerMode is similar to wmctrl Adam Vogt **20131219180748 Ignore-this: 3215bdf1c698c798eca8ed7f62a0f591 ] [Generalized XMonad.Hooks.ServerMode polson2 at hawk.iit.edu**20131216025100 Ignore-this: e58da3b168a1058f32982833ea25a739 ] [IfMax-Layout Ilya Portnov **20131201072634 Ignore-this: dac53f2a0505e740f05fdf03f1db0c21 This adds a new ("conditional") layout, IfMax, which simply runs one layout, if there are <= N windows, and else runs another layout. ] [fix UrgencyHook and add filterUrgencyHook Adam Vogt **20130924224738 Ignore-this: 3b7c62275701e6758397977c5c09b744 ] [export XMonad.Hooks.UrgencyHook.clearUrgency (issue 533) Adam Vogt **20130923031349 Ignore-this: dafe5763d9abcfa606f5c1a8cf5c57d6 ] [minor documentation fix: manageDocks doesn't do anything with struts, so don't claim it does Daniel Wagner **20130814125106 Ignore-this: a2610d6c1318ac0977abfc21d1b91632 ] [don't pretend to be LG3D in X.C.Dmwit because this confuses modern GTK Daniel Wagner **20130813211636 Ignore-this: 8f728dc1b4bf5e472d99419cc5920e51 ] [XMonad.Actions.UpdatePointer: generalise updatePointer Liyang HU **20130730071007 Ignore-this: 3374a62b6c63dcc152dbf843cd0577f0 ] [XMonad.Actions.UpdatePointer: document TowardsCentre Liyang HU **20130730053746 Ignore-this: 2d684b12e4fff0ebec254bea4a4546a3 ] [Haddock formatting in H.Minimize Adam Vogt **20130723155658 Ignore-this: 5db3186a51dec58f78954466ded339cb ] [Bump version (and xmonad dependency) to 0.12 Adam Vogt **20130720205857 Ignore-this: ce165178ca916223501f266339f1de39 This makes a breakage due to missing patches in core a bit more obvious. Previously you would have a build failure regarding some missing identifiers (def re-exported by XMonad from Data.Default), while after applying this patch it will be clear that xmonad-core needs to be updated. ] [Fix issue 551 by also getting manpath without -g flag. Adam Vogt **20130716030536 Ignore-this: ded2d51eb7b7697c0fdfaa8158d612df Instead of taking Ondrej's approach of figuring out which man (man-db or http://primates.ximian.com/~flucifredi/man/) is used by the system, just try both sets of flags. ] [Escape dzen markup and remove xmobar tags from window titles by default. Adam Vogt **20130708144813 Ignore-this: cf56bff752fbf78ea06d5c0cb755f615 The issue was that window titles, such as those set by, for example a browser, could set the window title to display something like normal title Which could be executed by xmobar (or dzen). This adds a ppTitleSanitize which does the above functions. This way when users override ppTitle, the benefits are not lost. Thanks to Ra?l Benencia and Joachim Breitner for bringing this to my attention. ] [DynamicBars-use-ExtensibleState gopsychonauts at gmail.com**20130618074755 Ignore-this: afacba51af2be8ede65b9bcf9b002a7 Hooks.DynamicBars was previously using an MVar and the unsafePerformIO hack ( http://www.haskell.org/haskellwiki/Top_level_mutable_state ) to store bar state. Since ExtensibleState exists to solve these sorts of problems, I've switched the file over to use unsafePerformIO instead. Some functions' types had to be changed to allow access to XState, but the public API is unchanged. ] [Catch exceptions when finding commands on PATH in Prompt.Shell Thomas Tuegel **20130616230219 Ignore-this: 5a4d08c80301864bc14ed784f1054c3f ] [Fix haddock parse error in X.A.LinkWorkspaces Adam Vogt **20130528133448 Ignore-this: 42f05cf8ca9e6d1ffae3bd20666d87ab ] [use Data.Default wherever possible, and deprecate the things it replaces Daniel Wagner **20130528013909 Ignore-this: 898458b1d2868a70dfb09faf473dc7aa ] [eliminate references to defaultConfig Daniel Wagner **20130528005825 Ignore-this: 37ae613e4b943e99c5200915b9d95e58 ] [minimal change needed to get xmonad-contrib to build with xmonad's data-default patch Daniel Wagner **20130528001040 Ignore-this: 291e4f6cd74fc2b808062e0369665170 ] [Remove unneeded XSync call in Layout.ShowWName Francesco Ariis **20130517153341 Ignore-this: 4d107c680572eff464c8f6ed9fabdd41 ] [Remove misleading comment: we definitely don't support ghc-6.6 anymore Adam Vogt **20130514215851 Ignore-this: 2d071cb05709a16763d039222264b426 ] [Fix module name in comment of X.L.Fullscreen Adam Vogt **20130514215727 Ignore-this: cb5cf18c301c5daf5e1a2527da1ef6bf ] [Minor update to cabal file (adding modules & maintainership) Adam Vogt **20130514215632 Ignore-this: 82785e02e544e1f797799bed5b5d9be2 ] [Remove trailing whitespace in X.A.LinkWorkspaces Adam Vogt **20130514215421 Ignore-this: 5015ab4468e7931876eb66b019af804c ] [Update documentation of LinkWorkspaces Module quesel at informatik.uni-oldenburg.de**20110328072813 Ignore-this: da863534931181f551c9c54bc4076c05 ] [Added a module for linking workspaces quesel at informatik.uni-oldenburg.de**20110210165018 Ignore-this: 1dba2164cc3387409873d33099596d91 This module provides a way to link certain workspaces in a multihead setup. That way, when switching to the first one the other heads display the linked workspaces. ] [Cache results from calcGap in ManageDocks Adam Vogt **20130425155811 Ignore-this: e5076fdbdfc68bc159424dd4e0f14456 http://www.haskell.org/pipermail/xmonad/2013-April/013670.html ] [Remove unnecessary contexts from L.MultiToggle Adam Vogt **20130217163356 Ignore-this: 6b0e413d8c3a58f62088c32a96c57c51 ] [Generalises modWorkspace to take any layout-transforming function gopsychonauts at gmail.com**20130501151425 Ignore-this: 28c7dc1f6216bb1ebdffef5434ccbcbd modWorkspace already was capable of modifying the layout with an arbitrary layout -> layout function, but its original type restricted it such that it could only apply a single LayoutModifier; this was often inconvenient, as for example it was not possible simply to compose LayoutModifiers for use with modWorkspace. This patch also reimplements onWorkspaces in terms of modWorkspaces, since with the latter's less restrictive type this is now possible. ] [since XMonad.Config.Dmwit mentions xmobar, we should include the associated .xmobarrc file Daniel Wagner **20130503194055 Ignore-this: 2f6d7536df81eb767262b79b60eb1b86 ] [warning police Daniel Wagner **20130502012700 Ignore-this: ae7412ac77c57492a7ad6c5f8f50b9eb ] [XMonad.Config.Dmwit Daniel Wagner **20130502012132 Ignore-this: 7402161579fd2e191b60a057d955e5ea ] [minor fixes to the haddock markup in X.L.IndependentScreens Daniel Wagner **20130411193849 Ignore-this: b6a139aa43fdb39fc1b86566c0c34c7a ] [add whenCurrentOn to X.L.IndependentScreens Daniel Wagner **20130408225251 Ignore-this: ceea3d391f270abc9ed8e52ce19fb1ac ] [Allow to specify the initial gaps' states in X.L.Gaps Paul Fertser **20130222072232 Ignore-this: 31596d918d0050e36ce3f64f56205a64 ] [should bump X11 dependency, too, to make sure we have getAtomName Daniel Wagner **20130225180527 Ignore-this: 260711f27551f18cc66afeb7b4846b9f ] [getAtomName is now defined in the X11 library Daniel Wagner **20130225180323 Ignore-this: 3b9e17c234679e98752a47c37132ee4e ] [Allow to limit maximum row count in X.Prompt completion window Paul Fertser **20130221122050 Ignore-this: 923656f02996f2de2b1336275392c5f9 On a keyboard-less device (such as a smartphone), where one has to use an on-screen keyboard, the maximum completion window height must be limited to avoid overlapping the keyboard. ] [Note in U.NameActions that xmonad core can list default keys now Adam Vogt **20130217233026 Ignore-this: 937bff636fa88171932d5192fe8e290b ] [Export U.NamedActions.addDescrKeys per evaryont's request. Adam Vogt **20130217232619 Ignore-this: a694a0a3ece70b52fba6e8f688d86344 ] [Add EWMH DEMANDS_ATTENTION support to UrgencyHook. Maarten de Vries **20130212181229 Ignore-this: 5a4b314d137676758fad9ec8f85ce422 Add support for the _NET_WM_STATE_DEMANDS_ATTENTION atom by treating it the same way as the WM_HINTS urgency flag. ] [Unconditionally set _NET_WORKAREA in ManageDocks Adam Vogt **20130117180851 Ignore-this: 9f57e53fba9573d8a92cf153beb7fe7a ] [spawn command when no completion is available (if alwaysHighlight is True); changes commandToComplete in Prompt/Shell to complete the whole word instead of using getLastWord c.lopez at kmels.net**20130209190456 Ignore-this: ca7d354bb301b555b64d5e76e31d10e8 ] [order-unindexed-ws-last matthewhague at zoho.com**20120703222726 Ignore-this: 4af8162ee8b16a60e8fd62fbc915d3c0 Changes the WorkspaceCompare module's comparison by index to put workspaces without an index last (rather than first). ] [SpawnOn modification for issue 523 Adam Vogt **20130114014642 Ignore-this: 703f7dc0f800366b752f0ec1cecb52e5 This moves the function to help clean up the `Spawner' to the ManageHook rather than in functions like spawnOn. Probably it makes no difference, the reason is because there's one manageSpawn function but many different so this way there are less functions to write. ] [Update L.TrackFloating.useTransient example code Adam Vogt **20130112041239 Ignore-this: e4e31cf1db742778c1d59d52fdbeed7a Suggest useTransient goes to the right of trackFloating which is the configuration actually tested. ] [Adapt ideas of issue 306 patch to a new modifier in L.TrackFloating Adam Vogt **20130112035701 Ignore-this: d54d27b71b97144ef0660f910fd464aa ] [Make X.A.CycleWS not rely on hidden WS order Dmitri Iouchtchenko **20130109023328 Ignore-this: 8717a154b33253c5df4e9a0ada4c2c3e ] [Add X.H.WorkspaceHistory Dmitri Iouchtchenko **20130109023307 Ignore-this: c9e7ce33a944facc27481dde52c7cc80 ] [Allow removing arbitrary workspaces Dmitri Iouchtchenko **20121231214343 Ignore-this: 6fce4bd3d0c5337e5122158583138e74 ] [Remove first-hidden restriction from X.A.DynamicWorkspaces.removeWorkspace' Dmitri Iouchtchenko **20121231214148 Ignore-this: 55fb0859e9a5f476a834ecbdb774aac8 ] [Add authorspellings file for `darcs show authors'. Adam Vogt **20130101040031 Ignore-this: c3198072ebc6a71d635bec4d8e2c78fd This authorspellings file includes a couple people who've contributed to xmonad (not XMonadContrib). When people have multiple addresses, the most recent one has been picked. ] [TAG 0.11 Adam Vogt **20130101014231 Ignore-this: 57cf32412fd1ce912811cb7fafe930f5 ] Patch bundle hash: 670d7e477470a517eb62278dd012400269244bdc -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From codesite-noreply at google.com Sat Apr 11 07:45:16 2015 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Sat, 11 Apr 2015 07:45:16 +0000 Subject: [xmonad] Issue 599 in xmonad: documentation on building xmonad is missing Message-ID: <0-3425899027203913298-17944620313692417879-codesite-noreply=google.com@googlecode.com> Status: New Owner: ---- New issue 599 by Ian... at gmail.com: documentation on building xmonad is missing https://code.google.com/p/xmonad/issues/detail?id=599 What steps will reproduce the problem? 1. http://xmonad.org/ 2. http://xmonad.org/download.html 3. run darcs get commands 4. http://xmonad.org/intro.html 5. This only explains how to build sources from hackage. 6. Look in the README file of the darcs sources. 7. Same as #5, except it also says how to install from a tarbal from http://code.haskell.org Also in the README is "Building: Building is quite straightforward" ... It then says how to install dependencies, then skips straight to running xmonad without actually saying how to build. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings From codesite-noreply at google.com Sat Apr 11 07:46:16 2015 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Sat, 11 Apr 2015 07:46:16 +0000 Subject: [xmonad] Issue 599 in xmonad: documentation on building xmonad is missing In-Reply-To: <0-3425899027203913298-17944620313692417879-codesite-noreply=google.com@googlecode.com> References: <0-3425899027203913298-17944620313692417879-codesite-noreply=google.com@googlecode.com> Message-ID: <1-3425899027203913298-17944620313692417879-codesite-noreply=google.com@googlecode.com> Comment #1 on issue 599 by Ian... at gmail.com: documentation on building xmonad is missing https://code.google.com/p/xmonad/issues/detail?id=599 Specifically, missing documentation on how to build from darcs. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings From codesite-noreply at google.com Sat Apr 11 07:57:43 2015 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Sat, 11 Apr 2015 07:57:43 +0000 Subject: [xmonad] Issue 600 in xmonad: conflicting install instructions Message-ID: <0-3425899027203913298-6357311470893718565-codesite-noreply=google.com@googlecode.com> Status: New Owner: ---- New issue 600 by Ian... at gmail.com: conflicting install instructions https://code.google.com/p/xmonad/issues/detail?id=600 What steps will reproduce the problem? 1. http://xmonad.org 2. follow link to http://xmonad.org/download.html 3. read: cabal install http://code.haskell.org/xmonad/xmonad.tar.gz 4. follow link to http://xmonad.org/intro.html 5. read conflicting instruction: cabal install xmonad Let's at least have a consistently documented and supported way to build, especially since building xmonad is quite prone to being broken in different circumstances. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings From codesite-noreply at google.com Sat Apr 11 07:59:34 2015 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Sat, 11 Apr 2015 07:59:34 +0000 Subject: [xmonad] Issue 601 in xmonad: xmonad-contrib fails to build with cabal install Message-ID: <0-3425899027203913298-12534276130769296481-codesite-noreply=google.com@googlecode.com> Status: New Owner: ---- New issue 601 by Ian... at gmail.com: xmonad-contrib fails to build with cabal install https://code.google.com/p/xmonad/issues/detail?id=601 What steps will reproduce the problem? 1. cabal install xmonad 2. cabal install xmonad-contrib Building xmonad-contrib-0.11.4... Preprocessing library xmonad-contrib-0.11.4... [ 1 of 226] Compiling XMonad.Util.StringProp ( XMonad/Util/StringProp.hs, dist/dist-sandbox-bce91598/build/XMonad/Util/StringProp.o ) [ 2 of 226] Compiling XMonad.Util.Replace ( XMonad/Util/Replace.hs, dist/dist-sandbox-bce91598/build/XMonad/Util/Replace.o ) [ 3 of 226] Compiling XMonad.Util.CustomKeys ( XMonad/Util/CustomKeys.hs, dist/dist-sandbox-bce91598/build/XMonad/Util/CustomKeys.o ) [ 4 of 226] Compiling XMonad.Layout.ThreeColumns ( XMonad/Layout/ThreeColumns.hs, dist/dist-sandbox-bce91598/build/XMonad/Layout/ThreeColumns.o ) [ 5 of 226] Compiling XMonad.Layout.StackTile ( XMonad/Layout/StackTile.hs, dist/dist-sandbox-bce91598/build/XMonad/Layout/StackTile.o ) [ 6 of 226] Compiling XMonad.Layout.Spiral ( XMonad/Layout/Spiral.hs, dist/dist-sandbox-bce91598/build/XMonad/Layout/Spiral.o ) [ 7 of 226] Compiling XMonad.Layout.Roledex ( XMonad/Layout/Roledex.hs, dist/dist-sandbox-bce91598/build/XMonad/Layout/Roledex.o ) [ 8 of 226] Compiling XMonad.Layout.ResizableTile ( XMonad/Layout/ResizableTile.hs, dist/dist-sandbox-bce91598/build/XMonad/Layout/ResizableTile.o ) [ 9 of 226] Compiling XMonad.Layout.OneBig ( XMonad/Layout/OneBig.hs, dist/dist-sandbox-bce91598/build/XMonad/Layout/OneBig.o ) [ 10 of 226] Compiling XMonad.Layout.MultiToggle ( XMonad/Layout/MultiToggle.hs, dist/dist-sandbox-bce91598/build/XMonad/Layout/MultiToggle.o ) [ 11 of 226] Compiling XMonad.Layout.MultiColumns ( XMonad/Layout/MultiColumns.hs, dist/dist-sandbox-bce91598/build/XMonad/Layout/MultiColumns.o ) [ 12 of 226] Compiling XMonad.Layout.MosaicAlt ( XMonad/Layout/MosaicAlt.hs, dist/dist-sandbox-bce91598/build/XMonad/Layout/MosaicAlt.o ) [ 13 of 226] Compiling XMonad.Layout.Mosaic ( XMonad/Layout/Mosaic.hs, dist/dist-sandbox-bce91598/build/XMonad/Layout/Mosaic.o ) [ 14 of 226] Compiling XMonad.Layout.LayoutBuilder ( XMonad/Layout/LayoutBuilder.hs, dist/dist-sandbox-bce91598/build/XMonad/Layout/LayoutBuilder.o ) [ 15 of 226] Compiling XMonad.Layout.HintedGrid ( XMonad/Layout/HintedGrid.hs, dist/dist-sandbox-bce91598/build/XMonad/Layout/HintedGrid.o ) [ 16 of 226] Compiling XMonad.Layout.Simplest ( XMonad/Layout/Simplest.hs, dist/dist-sandbox-bce91598/build/XMonad/Layout/Simplest.o ) [ 17 of 226] Compiling XMonad.Util.Stack ( XMonad/Util/Stack.hs, dist/dist-sandbox-bce91598/build/XMonad/Util/Stack.o ) [ 18 of 226] Compiling XMonad.Layout.Groups ( XMonad/Layout/Groups.hs, dist/dist-sandbox-bce91598/build/XMonad/Layout/Groups.o ) [ 19 of 226] Compiling XMonad.Layout.GridVariants ( XMonad/Layout/GridVariants.hs, dist/dist-sandbox-bce91598/build/XMonad/Layout/GridVariants.o ) [ 20 of 226] Compiling XMonad.Layout.Grid ( XMonad/Layout/Grid.hs, dist/dist-sandbox-bce91598/build/XMonad/Layout/Grid.o ) [ 21 of 226] Compiling XMonad.Layout.FixedColumn ( XMonad/Layout/FixedColumn.hs, dist/dist-sandbox-bce91598/build/XMonad/Layout/FixedColumn.o ) [ 22 of 226] Compiling XMonad.Layout.Dishes ( XMonad/Layout/Dishes.hs, dist/dist-sandbox-bce91598/build/XMonad/Layout/Dishes.o ) [ 23 of 226] Compiling XMonad.Util.Invisible ( XMonad/Util/Invisible.hs, dist/dist-sandbox-bce91598/build/XMonad/Util/Invisible.o ) XMonad/Util/Invisible.hs:31:59: Not in scope: type constructor or class ?Applicative? cabal: Error: some packages failed to install: xmonad-contrib-0.11.4 failed during the building phase. The exception was: ExitFailure 1 tried with ghc 7.8.3 and 7.8.4 cabal-install version 1.20.0.3 Tried to install to a sandbox -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings From carstenmattner at gmail.com Sat Apr 11 10:09:24 2015 From: carstenmattner at gmail.com (Carsten Mattner) Date: Sat, 11 Apr 2015 12:09:24 +0200 Subject: [xmonad] New release In-Reply-To: References: <87fvcxerhh.fsf@pmade.com> Message-ID: On Sun, Mar 29, 2015 at 1:59 PM, Carsten Mattner wrote: > On Wed, Mar 11, 2015 at 1:11 PM, Carsten Mattner > wrote: >> Some friendly suggestions: >> >> I'd very much like to see a release happen this month and start >> to get into a habit of at least a couple release a year. Infrequent releases >> may contribute to the perception of Darcs being the reason for >> project stalls. >> >> Someone with good writing skills might also want to communicate >> the nice Xmonad Prompt modules as advanced replacements for >> dmenu and one less external dependency and Xmonad-only >> feature like other window managers that don't require dmenu. >> Just a thought. > > GHC 7.10 is out and Darcs HEAD works. Time for release? > Communicating the Xmonad Prompt modules is icing on the > cake best done by someone with good writing skills but not > blocker for the release. Don't want to be that guy but what's blocking the release? >> On Tue, Mar 3, 2015 at 4:43 PM, Carsten Mattner >> wrote: >>> 7.10 works for me with Darcs HEAD. >>> >>> On Mon, Mar 2, 2015 at 7:08 PM, adam vogt wrote: >>>> Certainly. The hard deadline is the ghc-7.10 release which can't compile >>>> what's currently on hackage. The end of the week seems realistic to check: >>>> >>>> Release notes >>>> >>>> Broken links in contrib haddocks >>>> >>>> That we are compatible with ghc s back to 6.12 or so >>>> >>>> Regards, >>>> Adam >>>> >>>> On Mar 2, 2015 12:30 PM, "Carsten Mattner" wrote: >>>>> >>>>> On Tue, Dec 2, 2014 at 9:17 PM, Peter Jones wrote: >>>>> > Carsten Mattner >>>>> > writes: >>>>> >> Isn't it time for a new release? Been using xmonad from darcs without >>>>> >> issues >>>>> >> for a long time. >>>>> > >>>>> > +1. >>>>> > >>>>> > Also, xmonad-extras needs an update to support recent versions of >>>>> > libmpd. >>>>> >>>>> Can we cut a release? >>>>> _______________________________________________ >>>>> xmonad mailing list >>>>> xmonad at haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad From codesite-noreply at google.com Sat Apr 11 18:38:01 2015 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Sat, 11 Apr 2015 18:38:01 +0000 Subject: [xmonad] Issue 601 in xmonad: xmonad-contrib fails to build with cabal install In-Reply-To: <0-3425899027203913298-12534276130769296481-codesite-noreply=google.com@googlecode.com> References: <0-3425899027203913298-12534276130769296481-codesite-noreply=google.com@googlecode.com> Message-ID: <1-3425899027203913298-12534276130769296481-codesite-noreply=google.com@googlecode.com> Comment #1 on issue 601 by mimi... at gmail.com: xmonad-contrib fails to build with cabal install https://code.google.com/p/xmonad/issues/detail?id=601 is duplicate of issue 597 -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings From codesite-noreply at google.com Mon Apr 13 17:16:46 2015 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Mon, 13 Apr 2015 17:16:46 +0000 Subject: [xmonad] Issue 600 in xmonad: conflicting install instructions In-Reply-To: <0-3425899027203913298-6357311470893718565-codesite-noreply=google.com@googlecode.com> References: <0-3425899027203913298-6357311470893718565-codesite-noreply=google.com@googlecode.com> Message-ID: <1-3425899027203913298-6357311470893718565-codesite-noreply=google.com@googlecode.com> Comment #1 on issue 600 by vogt.a... at gmail.com: conflicting install instructions https://code.google.com/p/xmonad/issues/detail?id=600 All three options presented on download.html are supposed to work: - distro pkg - hackage - darcs get / tar.gz snapshot "cabal install http://code.haskell.org/xmonad/xmonad.tar.gz" is just there for people that have trouble installing darcs (such as archlinux currently), but for whatever reason would like to run the development version. We can remove "cabal install http://code.haskell.org/xmonad/xmonad.tar.gz" (PR https://github.com/davidlazar/xmonad.org), but that still leaves people the choice between using a release or using the bleeding edge. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings From codesite-noreply at google.com Tue Apr 14 09:49:44 2015 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Tue, 14 Apr 2015 09:49:44 +0000 Subject: [xmonad] Issue 600 in xmonad: conflicting install instructions In-Reply-To: <1-3425899027203913298-6357311470893718565-codesite-noreply=google.com@googlecode.com> References: <1-3425899027203913298-6357311470893718565-codesite-noreply=google.com@googlecode.com> <0-3425899027203913298-6357311470893718565-codesite-noreply=google.com@googlecode.com> Message-ID: <2-3425899027203913298-6357311470893718565-codesite-noreply=google.com@googlecode.com> Comment #2 on issue 600 by Ian... at gmail.com: conflicting install instructions https://code.google.com/p/xmonad/issues/detail?id=600 Having different ways of installing is great. There is just a little confusing inconsistency going on. And I actually wasn't super clear in my bug. Let me clarify. Background: http://xmonad.org/download.html is where users are funneled from the main page, it appears to overview the install methods, and leads users on to http://xmonad.org/intro.html which appears to be the complete documentation on install. 1. download.html says "After you've downloaded, follow the install instructions (link to intro.html)", then on intro.html, the tarbal you downloaded is never mentioned. So either remove the mention of downloading manually from hackage, or have an instruction which involves xmonad-.tar.gz on intro.html. I still don't know how you would install the tarball. cabal install xmonad-.tar.gz? The download link on hackage is not the easiest to find (at the bottom of the page), so I'd prefer steering people to the simpler cabal install method. 2. intro.html should mention the "cabal install http://code.haskell.org/xmonad/xmonad.tar.gz" method which was first mentioned on the download.html page or else it's confusing (this first page said I could do this, and now this other page looks like it's meant to cover everything, but it doesn't say I can do this). If this makes sense, I can write a patch and do a PR on github. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings From davama at gmail.com Tue Apr 14 12:15:18 2015 From: davama at gmail.com (Dave Macias) Date: Tue, 14 Apr 2015 08:15:18 -0400 Subject: [xmonad] xmonad: xmonad-extras 0.12 fails to build In-Reply-To: References: Message-ID: Thank you all for the replies. I've tried removing it by simply commenting it out, but no change. Assam, where would the parentheses go? I've fiddled with it but dont know where. This is the block of code that i assume you are referring to: XMonad.Actions.Volume infixl 1 <* (<*) :: Monad m => m a -> m b -> m a pa <* pb = pa >>= \a -> pb >> return a Thanks again Dave On Fri, Apr 10, 2015 at 12:35 AM, adam vogt wrote: > Hi. > > The fixity is different (infixl 1 not infixl 4) so using the one from > control.applicative means some parentheses have to be added. > > Regards, > Assam > On Apr 10, 2015 12:16 AM, "Carlos L?pez-Camey" wrote: > >> Hi Dave, by the results of hoogle *, it looks like (<*) is defined in >> Applicative. I think Applicative is a super class of Monad in newer GHC and >> is now included in the Prelude. So, I believe it would be safe to just >> remove it. >> >> * >> https://www.haskell.org/hoogle/?hoogle=Monad+m+%3D%3E+m+a+-%3E+m+b+-%3E+m+a >> >> Cheers >> >> 2015-04-09 21:55 GMT-06:00 Dave Macias : >> >>> Thanks for responding Brent. >>> >>> Not very good at haskell myself. >>> Im looking at the XMonad.Actions.Volume and there i find: >>> >>> infixl 1 <* >>> (<*) :: Monad m => m a -> m b -> m a >>> pa <* pb = pa >>= \a -> pb >> return a >>> >>> I'm assuming this is what you were referring to for solution (1). I've >>> been trying to play with it but i get mixed errors when building, how do i >>> rename? >>> Here is the code just in case im looking at it wrong: >>> >>> https://hackage.haskell.org/package/xmonad-extras-0.12/src/XMonad/Actions/Volume.hs >>> >>> I also plan to email the maintainer, but i would like to have this work >>> for educational purposes. >>> >>> Thanks, >>> Dave >>> >>> On Thu, Apr 9, 2015 at 10:04 AM, Brent Yorgey wrote: >>> >>>> It looks like XMonad.Actions.Volume defines an operator (<*), but as >>>> of base-4.8 an operator with that name has been added to the Prelude. The >>>> fix would be to either (1) rename the operator in XMonad.Actions.Volume, or >>>> (2) hide the operator from Prelude and tell everyone who wants to use >>>> XMonad.Actions.Volume.(<*) that they need to hide it from Prelude too. >>>> >>>> xmonad-extras is not officially a part of the xmonad project; you >>>> should contact the maintainers listed at >>>> http://hackage.haskell.org/package/xmonad-extras . >>>> >>>> -Brent >>>> >>>> On Mon, Apr 6, 2015 at 11:45 PM Dave Macias wrote: >>>> >>>>> This is my first time posting here so i hope im doing this right. >>>>> Just updated ghc to 7.10.1 and had to rebuild xmonad, xmonad-contrib, >>>>> and xmobar. >>>>> I also use xmonad-extras but it failed during the build. I tried using >>>>> cabal and also from source but both give same output: >>>>> >>>>> $ cabal install xmonad-extras >>>>> >>>>> Resolving dependencies... >>>>> Configuring xmonad-extras-0.12... >>>>> Building xmonad-extras-0.12... >>>>> Failed to install xmonad-extras-0.12 >>>>> Build log ( /home/dvmacias/.cabal/logs/xmonad-extras-0.12.log ): >>>>> Configuring xmonad-extras-0.12... >>>>> Building xmonad-extras-0.12... >>>>> Preprocessing library xmonad-extras-0.12... >>>>> [1 of 2] Compiling XMonad.Util.WindowPropertiesRE ( >>>>> XMonad/Util/WindowPropertiesRE.hs, >>>>> dist/build/XMonad/Util/WindowPropertiesRE.o ) >>>>> [2 of 2] Compiling XMonad.Actions.Volume ( XMonad/Actions/Volume.hs, >>>>> dist/build/XMonad/Actions/Volume.o ) >>>>> >>>>> XMonad/Actions/Volume.hs:173:23: >>>>> Ambiguous occurrence ?<*? >>>>> It could refer to either ?XMonad.Actions.Volume.<*?, >>>>> defined at XMonad/Actions/Volume.hs:66:4 >>>>> or ?Prelude.<*?, >>>>> imported from ?Prelude? at >>>>> XMonad/Actions/Volume.hs:15:8-28 >>>>> (and originally defined in ?GHC.Base?) >>>>> >>>>> XMonad/Actions/Volume.hs:173:43: >>>>> Ambiguous occurrence ?<*? >>>>> It could refer to either ?XMonad.Actions.Volume.<*?, >>>>> defined at XMonad/Actions/Volume.hs:66:4 >>>>> or ?Prelude.<*?, >>>>> imported from ?Prelude? at >>>>> XMonad/Actions/Volume.hs:15:8-28 >>>>> (and originally defined in ?GHC.Base?) >>>>> >>>>> XMonad/Actions/Volume.hs:200:62: >>>>> Ambiguous occurrence ?<*? >>>>> It could refer to either ?XMonad.Actions.Volume.<*?, >>>>> defined at XMonad/Actions/Volume.hs:66:4 >>>>> or ?Prelude.<*?, >>>>> imported from ?Prelude? at >>>>> XMonad/Actions/Volume.hs:15:8-28 >>>>> (and originally defined in ?GHC.Base?) >>>>> >>>>> XMonad/Actions/Volume.hs:215:32: >>>>> Ambiguous occurrence ?<*? >>>>> It could refer to either ?XMonad.Actions.Volume.<*?, >>>>> defined at XMonad/Actions/Volume.hs:66:4 >>>>> or ?Prelude.<*?, >>>>> imported from ?Prelude? at >>>>> XMonad/Actions/Volume.hs:15:8-28 >>>>> (and originally defined in ?GHC.Base?) >>>>> >>>>> XMonad/Actions/Volume.hs:225:58: >>>>> Ambiguous occurrence ?<*? >>>>> >>>>> It could refer to either ?XMonad.Actions.Volume.<*?, >>>>> defined at XMonad/Actions/Volume.hs:66:4 >>>>> or ?Prelude.<*?, >>>>> imported from ?Prelude? at >>>>> XMonad/Actions/Volume.hs:15:8-28 >>>>> (and originally defined in ?GHC.Base?) >>>>> cabal: Error: some packages failed to install: >>>>> xmonad-extras-0.12 failed during the building phase. The exception was: >>>>> ExitFailure 1 >>>>> >>>>> >>>>> I got to look at the log but it just has what i pasted above. System >>>>> is Arch 3.19.2-1-ARCH >>>>> >>>>> Any input is appreciated. >>>>> Thanks >>>>> dave >>>>> _______________________________________________ >>>>> xmonad mailing list >>>>> xmonad at haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad >>>>> >>>> >>> >>> _______________________________________________ >>> xmonad mailing list >>> xmonad at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad >>> >>> >> >> _______________________________________________ >> xmonad mailing list >> xmonad at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From auke at tulcod.com Tue Apr 14 12:41:48 2015 From: auke at tulcod.com (Auke Booij) Date: Tue, 14 Apr 2015 14:41:48 +0200 Subject: [xmonad] WaylandMonad Message-ID: A few weeks ago, I sent in a Google Summer of Code application for the haskell.org organization to work on porting Xmonad to wayland. The haskell organization has asked me to find a mentor for my application, which is the main reason for this email. If you are 1. an adult (sorry kids, Google's rules) 2. experienced with the Xmonad source 3. interested in wayland 4. willing to spend some time this summer on mentoring me then please contact me or someone in the haskell community to discuss mentoring options. The deadline for proposal matching is the 24th of April, so please contact me within this week (or better yet, as soon as possible). Without a mentor, I cannot get accepted for GSoC. I am already up to speed on wayland, so I think any Xmonad developer with some free time would make a great mentor. I attached my GSoC application below. Any comment on making Xmonad work on wayland is welcome as well. My current plan is to fork Xmonad and replace all the X bits by wayland bits - see also my proposal below. Greetings, Auke. Abstract === XMonad has, for a long time, been a flagship product of the Haskell community. With the arrival of wayland, XMonad is bound to look stuck in the past, and it's time for a port. Thanks to my previous work on wayland-related haskell libraries, this is now a viable project. Proposal === Background --- X11 has long been the de facto standard way for applications to display graphical user interfaces on the screen. For various reasons, a new project called wayland has been started, that can be seen as a successor of the X ecosystem, or at least can be seen as something that will play a very important role. Among others, GNOME is already working on wayland support, and plans to make it fully supported by version 3.18. This shows the relevance of wayland. XMonad is a flagship product of the Haskell community that is often cited as an example of the applicability of Haskell: its real world value. XMonad is a compositor (aka window manager) for the X11 ecosystem. In the new wayland ecosystem, one cannot reuse X11 compositors: they need to be partially rewritten. Goal --- I intend to fork XMonad and make it into a wayland compositor. Since the general ideas behind the X11 and the wayland protocol are not too different, this should be doable: we are still working with pointers and windows and input and output and renderings and messages. However, the wayland setup is technically very different from X11, since the central X11 server has been replaced by the compositor itself, and this means some very foundational code will need to be rewritten. I am the author of hayland [1], the haskell bindings to the wayland C library, as well as haskell-xkbcommon [2], the haskell bindings to the xkbcommon C library. With these two projects in place, the time is ripe for a wayland compositor written in haskell: the preliminaries are mostly there. As part of this project, I will have to invest some time in these two bindings projects as well (since they are quite new and have had little testing). For this reason, I intend to keep the scope of this project limited, and focus on getting some version of XMonad running on Wayland. I do not intend to change the architecture of XMonad, except wherever this would not require much more investment of time, and only as wished by the community. In other words: if you have anything that I should change about XMonad, and it is easy to switch to this new thing, then I'll use it. Any serious architectural changes will need to take place in a later stage. Deliverables --- - A working wayland compositor written in wayland, based on XMonad - Documentation of the source code (i.e. a technical document), user documentation (where this differs from XMonad) - Roadmap for further work: how should this project be continued into a next iteration of the XMonad project? Roadmap --- April/May: properly work my way through the XMonad source, and document things that will need changing June: Hack until it's working June+July: More hacking, also documentation August: Prepare a proper release, clean up code Bio --- I am currently studying for a Master of Logic in Amsterdam, and have a Master of Advanced Studies in Mathematics from Cambridge, UK, a BSc in Applied Mathematics and a BSc in Electrical Engineering (both from TU Delft). I have previously successfully finished GSoC (2010, with Gentoo) and SOCIS (in 2013, with PyBRML) (SOCIS is a GSoC-like program managed by the European Space Agency). I am the author of hayland [1], the haskell bindings to the wayland C library, as well as haskell-xkbcommon [2], the haskell bindings to the xkbcommon C library. The name of this fork is up for discussion. [1] https://github.com/tulcod/haskell-wayland [2] https://github.com/tulcod/haskell-xkbcommon From allbery.b at gmail.com Tue Apr 14 15:38:05 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 14 Apr 2015 11:38:05 -0400 Subject: [xmonad] Amended dynamic property patch Message-ID: Whoops! Year (what I get for copying the header), and I managed to miss the common case where the event isn't the one we care about. 1 patch for repository http://code.haskell.org/XMonadContrib: Tue Apr 14 11:36:57 EDT 2015 allbery.b at gmail.com * dynamicproperty Run a ManageHook from handleEventHook when a window property changes. You would use this to match e.g. browser windows whose title is not "final" until after the on-load hooks of the loaded document complete. New patches: [dynamicproperty allbery.b at gmail.com**20150414153657 Ignore-this: b15d78f8970d08b252ead72a19709b06 Run a ManageHook from handleEventHook when a window property changes. You would use this to match e.g. browser windows whose title is not "final" until after the on-load hooks of the loaded document complete. ] { addfile ./XMonad/Hooks/DynamicProperty.hs hunk ./XMonad/Hooks/DynamicProperty.hs 1 +----------------------------------------------------------------------------- +-- | +-- Module : XMonad.Hooks.DynamicProperty +-- Copyright : (c) Brandon S Allbery, 2015 +-- License : BSD3-style (see LICENSE) +-- +-- Maintainer : allbery.b at gmail.com +-- Stability : unstable +-- Portability : not portable +-- +-- Module to apply a ManageHook to an already-mapped window when a property +-- changes. This would commonly be used to match browser windows by title, +-- since the final title will only be set after (a) the window is mapped, +-- (b) its document has been loaded, (c) all load-time scripts have run. +-- (Don't blame browsers for this; it's inherent in HTML and the DOM. And +-- changing title dynamically is explicitly permitted by ICCCM and EWMH; +-- you don't really want to have your editor window umapped/remapped to +-- show the current document and modified state in the titlebar, do you?) +-- +-- This is a handleEventHook that triggers on a PropertyChange event. It +-- currently ignores properties being removed, in part because you can't +-- do anything useful in a ManageHook involving nonexistence of a property. +-- +----------------------------------------------------------------------------- + +module XMonad.Hooks.DynamicProperty where + +import XMonad +import Data.Monoid +import Control.Applicative +import Control.Monad (when) + +-- | +-- Run a 'ManageHook' when a specific property is changed on a window. Note +-- that this will run on any window which changes the property, so you should +-- be very specific in your 'MansgeHook' matching (lots of windows change +-- their titles on the fly!): +-- +-- dynamicPropertyChange "WM_NAME" (className =? "Iceweasel" <&&> title =? "whatever" --> doShift "2") +-- +-- Note that the fixity of (-->) won't allow it to be mixed with ($), so you +-- can't use the obvious $ shorthand. +-- +-- > dynamicPropertyChange "WM_NAME" $ title =? "Foo" --> doFloat -- won't work! +-- +-- Consider instead phrasing it like any +-- other 'ManageHook': +-- +-- > , handleEventHook = dynamicPropertyChange "WM_NAME" myDynHook <+> handleEventHook baseConfig +-- > +-- > {- ... -} +-- > +-- > myDynHook = composeAll [...] +-- +dynamicPropertyChange :: String -> ManageHook -> Event -> X All +dynamicPropertyChange prop hook PropertyEvent { ev_window = w, ev_atom = a, ev_propstate = ps } = do + pa <- getAtom prop + when (ps == propertyNewValue && a == pa) $ do + g <- appEndo <$> userCodeDef (Endo id) (runQuery hook w) + windows g + return (All False) -- so anything else also processes it +dynamicPropertyChange _ _ _ = return (All False) + +-- | A shorthand for the most common case, dynamic titles +dynamicTitle :: ManageHook -> Event -> X All +-- strictly, this should also check _NET_WM_NAME. practically, both will +-- change and each gets its own PropertyEvent, so we'd need to record that +-- we saw the event for that window and ignore the second one. Instead, just +-- trust that nobody sets only _NET_WM_NAME. (I'm sure this will prove false, +-- since there's always someone who can't bother being compliant.) +dynamicTitle = dynamicPropertyChange "WM_NAME" hunk ./xmonad-contrib.cabal 167 XMonad.Hooks.DynamicBars XMonad.Hooks.DynamicHooks XMonad.Hooks.DynamicLog + XMonad.Hooks.DynamicProperty XMonad.Hooks.DebugStack XMonad.Hooks.EwmhDesktops XMonad.Hooks.FadeInactive } Context: [minor doc fixes to X.C.Mate Daniel Wagner **20150330180752 Ignore-this: f35c2e5068adcf5a04727557078c8a6f ] [mate-comment-fixup allbery.b at gmail.com**20150330160523 Ignore-this: 687b5edc9220469f3e58abcfd4f6449c Correct the docstrings / comments in X.C.Mate, which still referenced gnomeConfig. Also update the session manager configuration to use dconf and a current (on Mint at least) path for the session config. ] [Add the ability to specify padding used with Maximize Peter Jones **20150309232939 Ignore-this: 71ac5db4513da0b7a45eb82ec184f4e3 ] [Don't restore windows when changing workspaces Peter Jones **20150310201709 Ignore-this: 5333205aa1a9fbc5c7844fad69561517 ] [New layout modifier: Hidden Peter Jones **20150309223036 Ignore-this: 5534fe18e642d1691a9b3f99341e082d A layout modifer that is meant to work with the BinarySpacePartition layout. By removing windows from the window set and adding them back at a later time, you can move windows to a different branch of the BSP tree. ] [Fixes to warnings with BSP layout anton.pirogov at gmail.com**20150315100041 Ignore-this: 7642710fdb2a866150875f2d521d19fd ] [Improved BinarySpacePartition, added Equalize,Balance and FocusParent and mouse resize support anton.pirogov at gmail.com**20150312145220 Ignore-this: 31b5d7bf38e5b391df266906deb5e382 ] [New layout module X.L.Dwindle nzeh at cs.dal.ca**20150315130913 Ignore-this: a1507e9eda6e6cabd679c2c3b50d9a38 This adds three layouts: Spiral is a reimplementation of X.L.Spiral.spiral with a (to me) more intuitive splitting policy. Dwindle is similar but pushes the smaller windows into a corner rather than into the center. Squeeze just stacks windows vertically or horizontally using geometrically decreasing sizes. ] [address warnings in P.Pass Adam Vogt **20150313015636 Ignore-this: 52e03c09c4d5339085e0306044de8977 ] [X.L.AvoidFloats more useful default settings ankaan at gmail.com**20150310212022 Ignore-this: af6535bace9219619858751eeeff6520 Changed default settings with the simple layout modifier. Instead of asking for a bool indicating if all windows should be avoided, no such bool is asked for. No windows are avoided by default. I think this will be a more useful default setting since it would be annoying if dialogue windows are avoided. The same functionality is possible with the advanced constructor. This will be easier for new users. This will break configurations using the old module, but this will not be much of an issue since the module has not been added to the repo as of this writing. ] [Resolve minor conflict in xmonad-contrib.cabal ankaan at gmail.com**20150306175436 Ignore-this: 24ae68c08107a574199b055989d38347 ] [X.L.AvoidFloats, like avoidStruts but for floats ankaan at gmail.com**20150306171702 Ignore-this: 3722d7787dd2429313f92f85f3ae1251 Checks for floating windows within the layout area and finds a maximum area rectangle within that does not overlap with any of the floating windows. This rectangle is used for all non-floating windows. This new functionality introduced problems with the recommended configuration of one of my other modules (X.A.FloatSnap.) A new and more reliable method of distinguishing between clicks and drags where therefore introduced in the new module X.A.AfterDrag. This does not break any prior use of FloatSnap, but will require changes in configuration if used together with AvoidFloats. (This is mentioned in the docs for AvoidFloats and I recommend using the new configuration method even if AvoidFloats is not in use.) ] [X.L.LayoutBuilder place active on top ankaan at gmail.com**20150306164200 Ignore-this: 69d718d0d044ee59a877fa0e63edc474 Make sure that the active layout area is placed on top of all other areas when placing windows. This makes overlapping areas usable. ] [Add rearrangers to X.A.GridSelect Dmitri Iouchtchenko **20130123044038 Ignore-this: ef0dc68e9b725953e69e7b039fe06e9a ] [Avoid repainting elements in X.A.GridSelect Dmitri Iouchtchenko **20130123043850 Ignore-this: 8e926cebc8d458a06a05f7457ae40b68 ] [Give a name to the initial state in X.A.GridSelect Dmitri Iouchtchenko **20130121061324 Ignore-this: 989ae20ccc3d5b1392f0694d5c62e759 ] [Add XMonad.Config.Bepo (Yorick Laupa) Adam Vogt **20150310214314 Ignore-this: 71dcf03f9ff80b645531004f95e9c600 ] [add instance Default WallpaperConf Adam Vogt **20150310214246 Ignore-this: 18e74f249b35726acd4b923ecce3085 ] [XMonad.Prompt.Pass: Handle hierachical password stores Joachim Breitner **20150218091816 Ignore-this: 2f0a02613780067d324b04a8cdb9c0ed pass stores its passwords in directories, so the contents of the directory store needs to be enumerated recursively. Alexander Sulfrian provided this patch on the mailinglist, which I tested (it works) and cleaned up slightly. ] [remove warnings and text dependency from H.WallpaperSetter Adam Vogt **20150310192933 Ignore-this: e637d782c13bed48bafbc1458b3f983f ] [Added the new hook WallpaperSetter anton.pirogov at gmail.com**20150228162335 Ignore-this: 7cbb2ab0d8f9f606f50253deebcf4163 ] [adjust an import to fix the build Adam Vogt **20150310182403 Ignore-this: 72f67dd2cb1cc6900269383124844c2b ] [merge conflicts in X.L.Spacing Adam Vogt **20150310182046 Ignore-this: f0830d6483d30d643e7e182e310ec042 I should have just applied Anton Pirogov March 4 patch. ] [Added messages to adjust the gap dynamically anton.pirogov at gmail.com**20150304082520 Ignore-this: 52b590c820db765796de41f38fffdf3c ] [X.L.Spacing needs -XPatternGuards now Adam Vogt **20150310181248 Ignore-this: d6b2b76fddbd9ad066e7cb39933f055a ] [add ConfirmPrompt (Antoine Beaupr?) Adam Vogt **20150310181036 Ignore-this: 65d74f05e82c66a3ff4f021d19ceb626 ] [Added messages to adjust the gap dynamically anton.pirogov at gmail.com**20150303210143 Ignore-this: 891ca1ccca183d6af8e4aa4bf6d843fb ] [add another extension to actually fix the build with ghc-7.10-RC1 Adam Vogt **20150124111939 Ignore-this: 26d6f1b4cb6d573ccf49e6baeca853e4 ] [BinarySpacePartition downstream changes benweitzman at gmail.com**20141110202259 Ignore-this: 42ecc2b07388ba0c7b3eac980256c17b Pulled in changes from my repo for this layout on github ( https://github.com/benweitzman/BinarySpacePartition) Includes a new mode for resizing windows in a more intuitive way, also contains a bug fix that was preventing users from resiving a window up. Includes changes from github users egasimus (Adam Avramov) and SolitaryCipher (Nick) ] [add XF86AudioMicMute to EZConfig (#582) Adam Vogt **20141222045306 Ignore-this: 1c91505b303e53b94da624230b3c893c ] [Generalize new workspace addition functions to support arbitrary insertion. nrujac at gmail.com**20141219002309 Ignore-this: 9f8c14b5aa9d398b3f167da0af1a8650 The current DynamicWorkspaces module only supports adding new workspaces at the start of the list of workspaces. This means when binding workspaces to keys based on the position in the list, key bindings can change as workspaces are added in removed in a far more destructive way than necessary. Instead, supporting appending and arbitrary insertion allows the user to determine where the new workspace should be added. This patch is a straight generalization of the addHiddenWorkspace' function. Rather than always using `(:)` to insert the new workspace into the list of workspaces, this patches causes it to use an arbitrary list insertion function instead. A few new functions are added to prevent breakage of external code while exported functions are left unchanged. List of new functions: appendWorkspace appendWorkspacePrompt addWorkspaceAt addHiddenWorkspaceAt Existing functions were modified to call their generalized brethren where possible without changing functionality. This patch should not change behavior for any existing users of this module. ] [address another bitSize/finiteBitSize warning Adam Vogt **20141222033300 Ignore-this: 549e519d25080c77e605dc983f0d239e ] [X.L.Master: Add FixMaster layout modifier Anton Vorontsov **20141220011339 Ignore-this: 82e9736853287f753248af41843ceb6b This layout modifier is useful for the case if you desire to add a master pane that has fixed width (it's fixed even if there is just one window opened). Especially nice feature if you don't want to have too wide terminal in a master pane. The layout is implemented as an addition to Master layout, so it reuses most of the code. ] [filepath dependency for P.Pass was left out Adam Vogt **20141221214129 Ignore-this: 98e63d7b17ac6ebabd8a6b081f5194a1 ] [remove unused imports Adam Vogt **20140815051234 Ignore-this: b2e5be31b70e6d31827e76bd8c00d200 ] [fix build with ghc-6.12 Adam Vogt **20140815051214 Ignore-this: d4c4da527db6c8affc151dc210631b85 ] [use FiniteBitSize with ghc >= 7.8 Adam Vogt **20140815051136 Ignore-this: 90f855fd72406fb3d2640a133d499188 ] [Layout.Spacing: Outer window edges now get as much spacing as inner ones Felix Crux **20141219223646 Ignore-this: 61363e97939fe857876c8252ac5f0302 Layout.Spacing applies a customizable amount of space around the outside of each window. At window edges where two windows meet, the total distance between them is therefore twice the customized value (one space value from each window). At the edge of the screen, however, the spacing is only applied once. This results in uneven amounts of spacing and differently-sized gaps on the screen. This patch extends the Spacing layout to include a further gap all around the edge of the screen, thus making all spaces around windows equal in size. ] [add filepath package dependency needed by Prompt.Pass Adam Vogt **20140909145216 Ignore-this: 588ec76e7fccb4219361da7024c98db4 filepath comes with ghc, and it's used by xmonad-core anyways ] [X.C.Prime: doc tweaks Devin Mullins **20141002075939 Ignore-this: 20d6b829b810f48b5e4b4c161b39b312 ] [X.A.Navigation2D: add convenience functions for setting config & keybindings Devin Mullins **20141002075757 Ignore-this: ed01137f03a531f73315ed503d1eb6ef 1. Added 'additionalNav2DKeys' which adds keybindings for the cartesian product of direction keys and (modifier, action) pairs given. 2. Added 'navigation2D' which combines that with 'withNavigation2DConfig'. 3. Added 'additionalNav2DKeysP' and 'navigation2DP' which do the same, but use the 'additionalKeysP' syntax. ] [X.C.Prime: doc fixes Devin Mullins **20141001075855 Ignore-this: dbbe00791b04df61dcd595c50333fba ] [X.C.Prime: add 'withScreens' and friends Devin Mullins **20141001075250 Ignore-this: eba37b1ff3da265a4dcc509f538fce4d The screen equivalent of 'withWorkspaces' lets you more easily define keys that move/swap between screens. Also, rename wsKeyspecs to wsKeys, and make a couple of doc tweaks. ] [Implement proper handling of dynamically changing hostname Anton Vorontsov **20140901072158 Ignore-this: 2aeac6d2161e666d40cda6a09f78b208 The module implements a proper way of finding out whether the window is remote or local. Just checking for a hostname and WM_CLIENT_MACHINE being equal is often not enough because the hostname is a changing subject (without any established notification mechanisms), and thus WM_CLIENT_MACHINE and the hostname can diverge even for a local window. This module solves the problem. As soon as there is a new window created, we check the hostname and WM_CLIENT_MACHINE, and then we cache the result into the XMONAD_REMOTE property. Notice that XMonad itself does not know anything about hostnames, nor does it have any dependency on Network.* modules. For this module it is not a problem: you can provide a mean to get the hostname through your config file (see usage). Or, if you don't like the hassle of handling dynamic hostnames (suppose your hostname never changes), it is also fine: this module will fallback to using environment variables. ] [Add Stoppable layout for power saving Anton Vorontsov **20140901072141 Ignore-this: a52805d9f3095cd7af48507847ed2fe3 This module implements a special kind of layout modifier, which when applied to a layout, causes xmonad to stop all non-visible processes. In a way, this is a sledge-hammer for applications that drain power. For example, given a web browser on a stoppable workspace, once the workspace is hidden the web browser will be stopped. Note that the stopped application won't be able to communicate with X11 clipboard. For this, the module actually stops applications after a certain delay, giving a chance for a user to complete copy-paste sequence. By default, the delay equals to 15 seconds, it is configurable via 'Stoppable' constructor. The stoppable modifier prepends a mark (by default equals to "Stoppable") to the layout description (alternatively, you can choose your own mark and use it with 'Stoppable' constructor). The stoppable layout (identified by a mark) spans to multiple workspaces, letting you to create groups of stoppable workspaces that only stop processes when none of the workspaces are visible, and conversely, unfreezing all processes even if one of the stoppable workspaces are visible. To stop the process we use signals, which works for most cases. For processes that tinker with signal handling (debuggers), another (Linux-centric) approach may be used. See https://www.kernel.org/doc/Documentation/cgroups/freezer-subsystem.txt ] [X.C.Prime: doc changes Devin Mullins **20140925203037 Ignore-this: 51204c1a9f2e6ed21228d2910417fd21 ] [X.C.Prime: add withWorkspaces et al. Devin Mullins **20140925203034 Ignore-this: 65f691270110cc5de13c950d9dcb0c17 This allows easier configuration of workspaces and their keybindings. Required generalizing the 'Prime' type, so lots of other lines changed in rather trivial ways. ] [X.C.Prime: add ifThenElse binding Devin Mullins **20140924191509 Ignore-this: ae775c418c27301b9c12d2a233502cec This is necessary for if-then-else support in the user's config. ] [X.C.Prime: doc fixes Devin Mullins **20140915080601 Ignore-this: 15e3c445a99d3b2d3a235aa76119797 ] [X.C.Prime: fix 'def' hyperlink in doc Devin Mullins **20140914075352 Ignore-this: a1de1d81a5f140ab7d90edbf393e9bda ] [XMonad.Config.Prime, a do-notation for config Devin Mullins **20140914064828 Ignore-this: f7397aa6e6efe5d76acebfa22c567baa Note that the use of RebindableSyntax is because of the need to vary the layoutHook type throughout the config. The alternative, using the existential Layout type, was rejected because it required TemplateHaskell in order to look nice, and TemplateHaskell is not portable. I've tried to make a version of (>>) that also worked on normal monads, but have had no luck as of yet. Maybe some intrepid soul can add it later. ] [X.P.Shell: fix doc typo me at twifkak.com**20130317115516 Ignore-this: bdd385a9142ed039a917d135e76293fe ] [reverse workspaces, so that switching to a dynamic workspace group restores the focus to the screen that was focused at group creation time nwfilardo at gmail.com**20140913174118 Ignore-this: b74c02b1892159694827e35122c2d517 ] [add filepath dependency, needed by new X.P.Pass module me at twifkak.com**20140913070926 Ignore-this: fec97086c1e66cf8a036265bd1a970a8 ] [add-new-xmonad-prompt-pass eniotna.t at gmail.com**20140829131928 Ignore-this: 11e85dfe3d24cef88d8d89f4e7b1ec0b This module provides 3 to ease passwords manipulation (generate, read, remove): - one to lookup passwords in the password-storage. - one to generate a password for a given password label that the user inputs. - one to delete a stored password for a given password label that the user inputs. All those prompts benefit from the completion system provided by the module . The password store is setuped through an environment variable PASSWORD_STORE_DIR. If this is set, use the content of the variable. Otherwise, the password store is located on user's home @$HOME\/.password-store at . Source: - The password storage implementation is < http://git.zx2c4.com/password-store the password-store cli>. - Inspired from ] [use Data.Map instead of Data.Map.Strict to support containers < 0.5 Adam Vogt **20140815043141 Ignore-this: 436d18657d8499f4ce57311e84503d9f ] [config-mate allbery.b at gmail.com**20140803020659 Ignore-this: d5de258c0a28cd5ba64a59cf37cd480a Initial support for the Mate desktop environment (http://mate-desktop.org). Based on existing Gnome 2 support, since Mate is a maintained fork of Gnome 2. ] [debug-managehook allbery.b at gmail.com**20140803020601 Ignore-this: 51f9255b496cca79e4a53e274c400ecc A set of hooks, and convenience combinators, to help with ManageHook debugging. Ordinary users may well want to use debugManageHookOn in normal configs, specifying a key sequence which can be pressed before running a command in order to capture debug information just for that command's main window. This is especially useful when trying to diagnose issues such as programs that do not play well with SpawnOn, or ManageHook matching on 'title' when the program does not set the window title until after it is mapped. ] [debug-debug allbery.b at gmail.com**20140803020530 Ignore-this: cbb2b1d99293e3a4d02a256c2733aeb0 Various fixes and enhancements to DebugWindow and DebugStack. ManageDebug requires these fixes, but some of them are significant even if not using ManageDebug. ] [derive Applicative instances to suppress AMP warning Adam Vogt **20140710163950 Ignore-this: c2110d07bccc61462c3fbf73c900aaa1 ] [clean up cabal file and drop support for base < 3 Adam Vogt **20140710013255 Ignore-this: 76b142e2b114604feac9b8e41cf71ab ] [add-duck-duck-go-search-engine eniotna.t at gmail.com**20140617174246 Ignore-this: 29bbfb2d07d9ddf36bf0268a4e255f81 ] [XSelection: getSelection: fix connection exhaustion bug (issue #573); include warning gwern at gwern.net**20140601025019 Ignore-this: add21190fc07338b243c2241cc746119 ] [Fix dbus-send call in XMonad.Config.Gnome md143rbh7f at gmail.com**20140129032114 Ignore-this: ed62458b55c8b34b77f73027eeee1a73 dbus-send --print-reply=string is invalid, but it was silently ignored until recently: http://cgit.freedesktop.org/dbus/dbus/commit/tools/dbus-send.c?id=c690ee4351f99ed5e629ffcf5f4a2edcd418d103 I've changed XMonad.Config.Gnome to run --print-reply=literal, since that's what the old behavior was. ] [warning police (unused variables) Adam Vogt **20140505001242 Ignore-this: a15b4d844b1da4f1f1f9b6095c968705 ] [This patch makes the Ssh extension works with **user** arguments in ssh, .e.g ssh admin at localhost. linxray at gmail.com**20140504091120 Ignore-this: 297673e11d3049c4f127aac3e172d361 ] [remove trailing whitespace in L.BinarySpacePartition Adam Vogt **20140501011943 Ignore-this: 8dd677978992e0854801b8f254463dc2 ] [replace Bound with the equivalent Direction2D Adam Vogt **20140501011540 Ignore-this: b1f1c256aba07f70918fe1d693c8087b ] [remove unused extension in BSP Adam Vogt **20140501011455 Ignore-this: a4962486b2aa3980536bff19a537451e ] [Add BinarySpacePartition layout benweitzman at gmail.com**20140430205848 Ignore-this: a85d1dc51bf54c59ae2bd9d948cc1088 ] [X.Actions.DynamicWorkspaceGroups: export new function addRawWSGroup Brent Yorgey **20140428142901 Ignore-this: a487882c9571bf91ff921d6561bb4cc6 ] [Remove unneeded context with the IfMax layout instance Adam Vogt **20140422221105 Ignore-this: 3b8ac316f56df6a84420754db769fb0 Extra constraints on instances are about as useful as -XDataTypeContexts ] [Adding side tabs and replacing TabbarLocation with Direction2D. nrujac at gmail.com**20140219200811 Ignore-this: edabeec973b4e0d61515818367689843 ] [warning police Daniel Wagner **20140316183747 Ignore-this: fd16435ccdd3fee8924723cc690cc239 ] [New module: XMonad.Util.WindowState Dmitry Bogatov **20140218100229 Ignore-this: 14a6fa263c423cd8cca3b2645b3930d7 Save almost arbitary data per window ] [Add side tabs to the tabbed layout. nrujac at gmail.com**20140213215247 Ignore-this: f81bafe9cb75a30ed6bbbe68cf5d66c0 ] [SpawnNamedPipe hlint cleanup cwills.dev at gmail.com**20140202213613 Ignore-this: dbb68c4c5522026bd108d0158e747b48 ] [document and cleanup SpawnNamedPipe cwills.dev at gmail.com**20140202211000 Ignore-this: b264278f1f1ab1f18b37245a5ff33136 ] [Added SpawnNamedPipe cwills.dev at gmail.com**20140202143415 Ignore-this: 87797ffffc8d0fd088482bd0c5baf0e ] [Make commandToComplete in XMonad.Prompt.Shell complete last word md143rbh7f at gmail.com**20140130200050 Ignore-this: b0fe22fdd7b9409835fd0ca069f2e01a The following change from 2013-02-09 breaks shell completion for me: hunk ./XMonad/Prompt/Shell.hs 65 + commandToComplete _ c = c It seems to be passing the entire string into compgen in order to get the file completions, but it should only pass the last word. I propose reverting this change. Comments are appreciated. ] [expose and document X.L.IndependentScreens.marshallSort Daniel Wagner **20140128212844 Ignore-this: 90c1437c6ffe1dbd8f4a4ed192097ec ] [ServerMode properly indent Adam Vogt **20131219201440 Ignore-this: 761b39c3e3c90b6123f068e8b1d34e5d ] [remove ServerMode tabs Adam Vogt **20131219201000 Ignore-this: f21448c248ec0ac289c309ed964ebcff ] [fix -Wall ServerMode Adam Vogt **20131219181030 Ignore-this: 708dd5fc60f43dee3d1da085002052f ] [documentation note that ServerMode is similar to wmctrl Adam Vogt **20131219180748 Ignore-this: 3215bdf1c698c798eca8ed7f62a0f591 ] [Generalized XMonad.Hooks.ServerMode polson2 at hawk.iit.edu**20131216025100 Ignore-this: e58da3b168a1058f32982833ea25a739 ] [IfMax-Layout Ilya Portnov **20131201072634 Ignore-this: dac53f2a0505e740f05fdf03f1db0c21 This adds a new ("conditional") layout, IfMax, which simply runs one layout, if there are <= N windows, and else runs another layout. ] [fix UrgencyHook and add filterUrgencyHook Adam Vogt **20130924224738 Ignore-this: 3b7c62275701e6758397977c5c09b744 ] [export XMonad.Hooks.UrgencyHook.clearUrgency (issue 533) Adam Vogt **20130923031349 Ignore-this: dafe5763d9abcfa606f5c1a8cf5c57d6 ] [minor documentation fix: manageDocks doesn't do anything with struts, so don't claim it does Daniel Wagner **20130814125106 Ignore-this: a2610d6c1318ac0977abfc21d1b91632 ] [don't pretend to be LG3D in X.C.Dmwit because this confuses modern GTK Daniel Wagner **20130813211636 Ignore-this: 8f728dc1b4bf5e472d99419cc5920e51 ] [XMonad.Actions.UpdatePointer: generalise updatePointer Liyang HU **20130730071007 Ignore-this: 3374a62b6c63dcc152dbf843cd0577f0 ] [XMonad.Actions.UpdatePointer: document TowardsCentre Liyang HU **20130730053746 Ignore-this: 2d684b12e4fff0ebec254bea4a4546a3 ] [Haddock formatting in H.Minimize Adam Vogt **20130723155658 Ignore-this: 5db3186a51dec58f78954466ded339cb ] [Bump version (and xmonad dependency) to 0.12 Adam Vogt **20130720205857 Ignore-this: ce165178ca916223501f266339f1de39 This makes a breakage due to missing patches in core a bit more obvious. Previously you would have a build failure regarding some missing identifiers (def re-exported by XMonad from Data.Default), while after applying this patch it will be clear that xmonad-core needs to be updated. ] [Fix issue 551 by also getting manpath without -g flag. Adam Vogt **20130716030536 Ignore-this: ded2d51eb7b7697c0fdfaa8158d612df Instead of taking Ondrej's approach of figuring out which man (man-db or http://primates.ximian.com/~flucifredi/man/) is used by the system, just try both sets of flags. ] [Escape dzen markup and remove xmobar tags from window titles by default. Adam Vogt **20130708144813 Ignore-this: cf56bff752fbf78ea06d5c0cb755f615 The issue was that window titles, such as those set by, for example a browser, could set the window title to display something like normal title Which could be executed by xmobar (or dzen). This adds a ppTitleSanitize which does the above functions. This way when users override ppTitle, the benefits are not lost. Thanks to Ra?l Benencia and Joachim Breitner for bringing this to my attention. ] [DynamicBars-use-ExtensibleState gopsychonauts at gmail.com**20130618074755 Ignore-this: afacba51af2be8ede65b9bcf9b002a7 Hooks.DynamicBars was previously using an MVar and the unsafePerformIO hack ( http://www.haskell.org/haskellwiki/Top_level_mutable_state ) to store bar state. Since ExtensibleState exists to solve these sorts of problems, I've switched the file over to use unsafePerformIO instead. Some functions' types had to be changed to allow access to XState, but the public API is unchanged. ] [Catch exceptions when finding commands on PATH in Prompt.Shell Thomas Tuegel **20130616230219 Ignore-this: 5a4d08c80301864bc14ed784f1054c3f ] [Fix haddock parse error in X.A.LinkWorkspaces Adam Vogt **20130528133448 Ignore-this: 42f05cf8ca9e6d1ffae3bd20666d87ab ] [use Data.Default wherever possible, and deprecate the things it replaces Daniel Wagner **20130528013909 Ignore-this: 898458b1d2868a70dfb09faf473dc7aa ] [eliminate references to defaultConfig Daniel Wagner **20130528005825 Ignore-this: 37ae613e4b943e99c5200915b9d95e58 ] [minimal change needed to get xmonad-contrib to build with xmonad's data-default patch Daniel Wagner **20130528001040 Ignore-this: 291e4f6cd74fc2b808062e0369665170 ] [Remove unneeded XSync call in Layout.ShowWName Francesco Ariis **20130517153341 Ignore-this: 4d107c680572eff464c8f6ed9fabdd41 ] [Remove misleading comment: we definitely don't support ghc-6.6 anymore Adam Vogt **20130514215851 Ignore-this: 2d071cb05709a16763d039222264b426 ] [Fix module name in comment of X.L.Fullscreen Adam Vogt **20130514215727 Ignore-this: cb5cf18c301c5daf5e1a2527da1ef6bf ] [Minor update to cabal file (adding modules & maintainership) Adam Vogt **20130514215632 Ignore-this: 82785e02e544e1f797799bed5b5d9be2 ] [Remove trailing whitespace in X.A.LinkWorkspaces Adam Vogt **20130514215421 Ignore-this: 5015ab4468e7931876eb66b019af804c ] [Update documentation of LinkWorkspaces Module quesel at informatik.uni-oldenburg.de**20110328072813 Ignore-this: da863534931181f551c9c54bc4076c05 ] [Added a module for linking workspaces quesel at informatik.uni-oldenburg.de**20110210165018 Ignore-this: 1dba2164cc3387409873d33099596d91 This module provides a way to link certain workspaces in a multihead setup. That way, when switching to the first one the other heads display the linked workspaces. ] [Cache results from calcGap in ManageDocks Adam Vogt **20130425155811 Ignore-this: e5076fdbdfc68bc159424dd4e0f14456 http://www.haskell.org/pipermail/xmonad/2013-April/013670.html ] [Remove unnecessary contexts from L.MultiToggle Adam Vogt **20130217163356 Ignore-this: 6b0e413d8c3a58f62088c32a96c57c51 ] [Generalises modWorkspace to take any layout-transforming function gopsychonauts at gmail.com**20130501151425 Ignore-this: 28c7dc1f6216bb1ebdffef5434ccbcbd modWorkspace already was capable of modifying the layout with an arbitrary layout -> layout function, but its original type restricted it such that it could only apply a single LayoutModifier; this was often inconvenient, as for example it was not possible simply to compose LayoutModifiers for use with modWorkspace. This patch also reimplements onWorkspaces in terms of modWorkspaces, since with the latter's less restrictive type this is now possible. ] [since XMonad.Config.Dmwit mentions xmobar, we should include the associated .xmobarrc file Daniel Wagner **20130503194055 Ignore-this: 2f6d7536df81eb767262b79b60eb1b86 ] [warning police Daniel Wagner **20130502012700 Ignore-this: ae7412ac77c57492a7ad6c5f8f50b9eb ] [XMonad.Config.Dmwit Daniel Wagner **20130502012132 Ignore-this: 7402161579fd2e191b60a057d955e5ea ] [minor fixes to the haddock markup in X.L.IndependentScreens Daniel Wagner **20130411193849 Ignore-this: b6a139aa43fdb39fc1b86566c0c34c7a ] [add whenCurrentOn to X.L.IndependentScreens Daniel Wagner **20130408225251 Ignore-this: ceea3d391f270abc9ed8e52ce19fb1ac ] [Allow to specify the initial gaps' states in X.L.Gaps Paul Fertser **20130222072232 Ignore-this: 31596d918d0050e36ce3f64f56205a64 ] [should bump X11 dependency, too, to make sure we have getAtomName Daniel Wagner **20130225180527 Ignore-this: 260711f27551f18cc66afeb7b4846b9f ] [getAtomName is now defined in the X11 library Daniel Wagner **20130225180323 Ignore-this: 3b9e17c234679e98752a47c37132ee4e ] [Allow to limit maximum row count in X.Prompt completion window Paul Fertser **20130221122050 Ignore-this: 923656f02996f2de2b1336275392c5f9 On a keyboard-less device (such as a smartphone), where one has to use an on-screen keyboard, the maximum completion window height must be limited to avoid overlapping the keyboard. ] [Note in U.NameActions that xmonad core can list default keys now Adam Vogt **20130217233026 Ignore-this: 937bff636fa88171932d5192fe8e290b ] [Export U.NamedActions.addDescrKeys per evaryont's request. Adam Vogt **20130217232619 Ignore-this: a694a0a3ece70b52fba6e8f688d86344 ] [Add EWMH DEMANDS_ATTENTION support to UrgencyHook. Maarten de Vries **20130212181229 Ignore-this: 5a4b314d137676758fad9ec8f85ce422 Add support for the _NET_WM_STATE_DEMANDS_ATTENTION atom by treating it the same way as the WM_HINTS urgency flag. ] [Unconditionally set _NET_WORKAREA in ManageDocks Adam Vogt **20130117180851 Ignore-this: 9f57e53fba9573d8a92cf153beb7fe7a ] [spawn command when no completion is available (if alwaysHighlight is True); changes commandToComplete in Prompt/Shell to complete the whole word instead of using getLastWord c.lopez at kmels.net**20130209190456 Ignore-this: ca7d354bb301b555b64d5e76e31d10e8 ] [order-unindexed-ws-last matthewhague at zoho.com**20120703222726 Ignore-this: 4af8162ee8b16a60e8fd62fbc915d3c0 Changes the WorkspaceCompare module's comparison by index to put workspaces without an index last (rather than first). ] [SpawnOn modification for issue 523 Adam Vogt **20130114014642 Ignore-this: 703f7dc0f800366b752f0ec1cecb52e5 This moves the function to help clean up the `Spawner' to the ManageHook rather than in functions like spawnOn. Probably it makes no difference, the reason is because there's one manageSpawn function but many different so this way there are less functions to write. ] [Update L.TrackFloating.useTransient example code Adam Vogt **20130112041239 Ignore-this: e4e31cf1db742778c1d59d52fdbeed7a Suggest useTransient goes to the right of trackFloating which is the configuration actually tested. ] [Adapt ideas of issue 306 patch to a new modifier in L.TrackFloating Adam Vogt **20130112035701 Ignore-this: d54d27b71b97144ef0660f910fd464aa ] [Make X.A.CycleWS not rely on hidden WS order Dmitri Iouchtchenko **20130109023328 Ignore-this: 8717a154b33253c5df4e9a0ada4c2c3e ] [Add X.H.WorkspaceHistory Dmitri Iouchtchenko **20130109023307 Ignore-this: c9e7ce33a944facc27481dde52c7cc80 ] [Allow removing arbitrary workspaces Dmitri Iouchtchenko **20121231214343 Ignore-this: 6fce4bd3d0c5337e5122158583138e74 ] [Remove first-hidden restriction from X.A.DynamicWorkspaces.removeWorkspace' Dmitri Iouchtchenko **20121231214148 Ignore-this: 55fb0859e9a5f476a834ecbdb774aac8 ] [Add authorspellings file for `darcs show authors'. Adam Vogt **20130101040031 Ignore-this: c3198072ebc6a71d635bec4d8e2c78fd This authorspellings file includes a couple people who've contributed to xmonad (not XMonadContrib). When people have multiple addresses, the most recent one has been picked. ] [TAG 0.11 Adam Vogt **20130101014231 Ignore-this: 57cf32412fd1ce912811cb7fafe930f5 ] Patch bundle hash: a028a7816d7ae8b3965477f94af4d3a1f7f92a13 -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at thestever.net Tue Apr 14 17:31:12 2015 From: steve at thestever.net (Steve Quezadas) Date: Tue, 14 Apr 2015 10:31:12 -0700 Subject: [xmonad] xmonad with emacs Message-ID: <552D4EE0.2090903@thestever.net> Hello, I am using xmonad and so far I love it! However, there seems to be a keybinding conflict (I think) with emacs. Control-space is the "set-mark-command" option in emacs and it does not seem to work when xmonad is present. The alternative keybind (Control-@) seems to work though. When I take xmonad off, the keybind works again. Not sure what is going on, I checked the FAQ and the maillist history and no one seems to be having this problem which is strange since emacs is a fairly common program My config file is fairly straightforward: import XMonad import XMonad.Config.Gnome main = xmonad gnomeConfig { modMask = mod4Mask -- Use Super instead of Alt -- more changes } I am using Ubuntu 14.04.2 with xmonad version 0.11 Has anyone used xmonad with emacs before? I remapped the meta key to the super key, thinking that this may cause the conflict but it didn't fix it. - Steve From allbery.b at gmail.com Tue Apr 14 17:49:40 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 14 Apr 2015 13:49:40 -0400 Subject: [xmonad] xmonad with emacs In-Reply-To: <552D4EE0.2090903@thestever.net> References: <552D4EE0.2090903@thestever.net> Message-ID: On Tue, Apr 14, 2015 at 1:31 PM, Steve Quezadas wrote: > I am using xmonad and so far I love it! However, there seems to be a > keybinding conflict (I think) with emacs. Control-space is the > "set-mark-command" option in emacs and it does not seem to work when > xmonad is present. The alternative keybind (Control-@) seems to work > though. When I take xmonad off, the keybind works again. > What's the other window manager / desktop environment? My guess is it loads a different keymap which sets up control-space to produce NUL. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From vogt.adam at gmail.com Tue Apr 14 18:24:51 2015 From: vogt.adam at gmail.com (adam vogt) Date: Tue, 14 Apr 2015 14:24:51 -0400 Subject: [xmonad] xmonad: xmonad-extras 0.12 fails to build In-Reply-To: References: Message-ID: I mean an expression like: > headerLine >> playbackChannels >>= volumes <* eof needs parentheses like: (headerLine >> playbackChannels >>= volumes) <* eof if we were to use the inflxl 4 <* On Tue, Apr 14, 2015 at 8:15 AM, Dave Macias wrote: > Thank you all for the replies. > I've tried removing it by simply commenting it out, but no change. > Assam, where would the parentheses go? I've fiddled with it but dont know > where. This is the block of code that i assume you are referring to: > XMonad.Actions.Volume > infixl 1 <* > (<*) :: Monad m => m a -> m b -> m a > pa <* pb = pa >>= \a -> pb >> return a > > Thanks again > Dave > > > On Fri, Apr 10, 2015 at 12:35 AM, adam vogt wrote: > >> Hi. >> >> The fixity is different (infixl 1 not infixl 4) so using the one from >> control.applicative means some parentheses have to be added. >> >> Regards, >> Assam >> On Apr 10, 2015 12:16 AM, "Carlos L?pez-Camey" wrote: >> >>> Hi Dave, by the results of hoogle *, it looks like (<*) is defined in >>> Applicative. I think Applicative is a super class of Monad in newer GHC and >>> is now included in the Prelude. So, I believe it would be safe to just >>> remove it. >>> >>> * >>> https://www.haskell.org/hoogle/?hoogle=Monad+m+%3D%3E+m+a+-%3E+m+b+-%3E+m+a >>> >>> Cheers >>> >>> 2015-04-09 21:55 GMT-06:00 Dave Macias : >>> >>>> Thanks for responding Brent. >>>> >>>> Not very good at haskell myself. >>>> Im looking at the XMonad.Actions.Volume and there i find: >>>> >>>> infixl 1 <* >>>> (<*) :: Monad m => m a -> m b -> m a >>>> pa <* pb = pa >>= \a -> pb >> return a >>>> >>>> I'm assuming this is what you were referring to for solution (1). I've >>>> been trying to play with it but i get mixed errors when building, how do i >>>> rename? >>>> Here is the code just in case im looking at it wrong: >>>> >>>> https://hackage.haskell.org/package/xmonad-extras-0.12/src/XMonad/Actions/Volume.hs >>>> >>>> I also plan to email the maintainer, but i would like to have this work >>>> for educational purposes. >>>> >>>> Thanks, >>>> Dave >>>> >>>> On Thu, Apr 9, 2015 at 10:04 AM, Brent Yorgey >>>> wrote: >>>> >>>>> It looks like XMonad.Actions.Volume defines an operator (<*), but as >>>>> of base-4.8 an operator with that name has been added to the Prelude. The >>>>> fix would be to either (1) rename the operator in XMonad.Actions.Volume, or >>>>> (2) hide the operator from Prelude and tell everyone who wants to use >>>>> XMonad.Actions.Volume.(<*) that they need to hide it from Prelude too. >>>>> >>>>> xmonad-extras is not officially a part of the xmonad project; you >>>>> should contact the maintainers listed at >>>>> http://hackage.haskell.org/package/xmonad-extras . >>>>> >>>>> -Brent >>>>> >>>>> On Mon, Apr 6, 2015 at 11:45 PM Dave Macias wrote: >>>>> >>>>>> This is my first time posting here so i hope im doing this right. >>>>>> Just updated ghc to 7.10.1 and had to rebuild xmonad, xmonad-contrib, >>>>>> and xmobar. >>>>>> I also use xmonad-extras but it failed during the build. I tried >>>>>> using cabal and also from source but both give same output: >>>>>> >>>>>> $ cabal install xmonad-extras >>>>>> >>>>>> Resolving dependencies... >>>>>> Configuring xmonad-extras-0.12... >>>>>> Building xmonad-extras-0.12... >>>>>> Failed to install xmonad-extras-0.12 >>>>>> Build log ( /home/dvmacias/.cabal/logs/xmonad-extras-0.12.log ): >>>>>> Configuring xmonad-extras-0.12... >>>>>> Building xmonad-extras-0.12... >>>>>> Preprocessing library xmonad-extras-0.12... >>>>>> [1 of 2] Compiling XMonad.Util.WindowPropertiesRE ( >>>>>> XMonad/Util/WindowPropertiesRE.hs, >>>>>> dist/build/XMonad/Util/WindowPropertiesRE.o ) >>>>>> [2 of 2] Compiling XMonad.Actions.Volume ( XMonad/Actions/Volume.hs, >>>>>> dist/build/XMonad/Actions/Volume.o ) >>>>>> >>>>>> XMonad/Actions/Volume.hs:173:23: >>>>>> Ambiguous occurrence ?<*? >>>>>> It could refer to either ?XMonad.Actions.Volume.<*?, >>>>>> defined at XMonad/Actions/Volume.hs:66:4 >>>>>> or ?Prelude.<*?, >>>>>> imported from ?Prelude? at >>>>>> XMonad/Actions/Volume.hs:15:8-28 >>>>>> (and originally defined in ?GHC.Base?) >>>>>> >>>>>> XMonad/Actions/Volume.hs:173:43: >>>>>> Ambiguous occurrence ?<*? >>>>>> It could refer to either ?XMonad.Actions.Volume.<*?, >>>>>> defined at XMonad/Actions/Volume.hs:66:4 >>>>>> or ?Prelude.<*?, >>>>>> imported from ?Prelude? at >>>>>> XMonad/Actions/Volume.hs:15:8-28 >>>>>> (and originally defined in ?GHC.Base?) >>>>>> >>>>>> XMonad/Actions/Volume.hs:200:62: >>>>>> Ambiguous occurrence ?<*? >>>>>> It could refer to either ?XMonad.Actions.Volume.<*?, >>>>>> defined at XMonad/Actions/Volume.hs:66:4 >>>>>> or ?Prelude.<*?, >>>>>> imported from ?Prelude? at >>>>>> XMonad/Actions/Volume.hs:15:8-28 >>>>>> (and originally defined in ?GHC.Base?) >>>>>> >>>>>> XMonad/Actions/Volume.hs:215:32: >>>>>> Ambiguous occurrence ?<*? >>>>>> It could refer to either ?XMonad.Actions.Volume.<*?, >>>>>> defined at XMonad/Actions/Volume.hs:66:4 >>>>>> or ?Prelude.<*?, >>>>>> imported from ?Prelude? at >>>>>> XMonad/Actions/Volume.hs:15:8-28 >>>>>> (and originally defined in ?GHC.Base?) >>>>>> >>>>>> XMonad/Actions/Volume.hs:225:58: >>>>>> Ambiguous occurrence ?<*? >>>>>> >>>>>> It could refer to either ?XMonad.Actions.Volume.<*?, >>>>>> defined at XMonad/Actions/Volume.hs:66:4 >>>>>> or ?Prelude.<*?, >>>>>> imported from ?Prelude? at >>>>>> XMonad/Actions/Volume.hs:15:8-28 >>>>>> (and originally defined in ?GHC.Base?) >>>>>> cabal: Error: some packages failed to install: >>>>>> xmonad-extras-0.12 failed during the building phase. The exception >>>>>> was: >>>>>> ExitFailure 1 >>>>>> >>>>>> >>>>>> I got to look at the log but it just has what i pasted above. System >>>>>> is Arch 3.19.2-1-ARCH >>>>>> >>>>>> Any input is appreciated. >>>>>> Thanks >>>>>> dave >>>>>> _______________________________________________ >>>>>> xmonad mailing list >>>>>> xmonad at haskell.org >>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> xmonad mailing list >>>> xmonad at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad >>>> >>>> >>> >>> _______________________________________________ >>> xmonad mailing list >>> xmonad at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From codesite-noreply at google.com Tue Apr 14 18:26:17 2015 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Tue, 14 Apr 2015 18:26:17 +0000 Subject: [xmonad] Issue 596 in xmonad: xmonad-extras do not compile with GHC 7.10 In-Reply-To: <1-3425899027203913298-6386447108504701233-codesite-noreply=google.com@googlecode.com> References: <1-3425899027203913298-6386447108504701233-codesite-noreply=google.com@googlecode.com> <0-3425899027203913298-6386447108504701233-codesite-noreply=google.com@googlecode.com> Message-ID: <2-3425899027203913298-6386447108504701233-codesite-noreply=google.com@googlecode.com> Updates: Status: Fixed Comment #2 on issue 596 by vogt.a... at gmail.com: xmonad-extras do not compile with GHC 7.10 https://code.google.com/p/xmonad/issues/detail?id=596 I've done the xmonad-extras release -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings From allbery.b at gmail.com Tue Apr 14 18:41:17 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 14 Apr 2015 14:41:17 -0400 Subject: [xmonad] trying again: Dynamic properties patch Message-ID: As an attachment this time, apparently gmail mangled the previous attempt(s). This patch somewhat hackily enables matching things such as browser windows where the title isn't set properly until "long" after the window is mapped, because of the way HTML+DOM allows it to be set dynamically by scripts or etc. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: dynamicproperty.dpatch Type: application/octet-stream Size: 38202 bytes Desc: not available URL: From steve at thestever.net Tue Apr 14 19:24:00 2015 From: steve at thestever.net (Steve Quezadas) Date: Tue, 14 Apr 2015 12:24:00 -0700 Subject: [xmonad] xmonad with emacs In-Reply-To: References: <552D4EE0.2090903@thestever.net> <552D6002.5090108@thestever.net> Message-ID: <552D6950.7060702@thestever.net> Oh, sorry, I meant to reply to the list, not you individually! The "reply to" command is not working right for some reason. I will check when I get home to see if my windows manager is somehow mucking things up. - Steve On 4/14/2015 11:50 AM, Tikhon Jelvis wrote: > Oh, I'm sorry, I assumed the `-- more changes' comment was a placeholder > for, well, more changes! If that's all you have, it's probably an issue > with something besides XMonad itself?Brandon's suggestion sounds > plausible. I'm not sure how to check that myself, I'm afraid. > > Also, I don't know if you did this on purpose, but you only sent this > message to me, not to the whole list. Keeping the conversation on the > list proper could be useful because other people might be able to help. > (It's something it took me a while to get used to myself, and I'm still > not too certain on good list etiquette :P.) > > On Tue, Apr 14, 2015 at 11:44 AM, Steve Quezadas > wrote: > > Interesting. I've used Emacs with XMonad and never had this problem. > > Are you running Emacs in X mode or in a terminal emulator? Also, > what > happens if you try this with as close to a stock XMonad as possible: > comment out all the parts of your config except for the modMask > setting. > > > I am using xmonad is x mode (I think, I'm basically using a > graphical user interface). My config is as stock as they come. This > is the whole thing: > > import XMonad > import XMonad.Config.Gnome > > main = xmonad gnomeConfig > { modMask = mod4Mask -- Use Super instead of Alt > -- more changes > } > > > The only one line that's differnt is the modMask line which remaps > the "alt" key to "super" key for xmonad stuff. > > - Steve > > From davama at gmail.com Tue Apr 14 21:21:05 2015 From: davama at gmail.com (davama at gmail.com) Date: Tue, 14 Apr 2015 14:21:05 -0700 (PDT) Subject: [xmonad] xmonad: xmonad-extras 0.12 fails to build In-Reply-To: References: Message-ID: <1429046465598.63a4581@Nodemailer> Looks like maintainer updated the package. Do i have to do anything to close this? Thanks all for support Dave ? Sent from iPhone On Tue, Apr 14, 2015 at 2:24 PM, adam vogt wrote: > I mean an expression like: >> headerLine >> playbackChannels >>= volumes <* eof > needs parentheses like: > (headerLine >> playbackChannels >>= volumes) <* eof > if we were to use the inflxl 4 <* > On Tue, Apr 14, 2015 at 8:15 AM, Dave Macias wrote: >> Thank you all for the replies. >> I've tried removing it by simply commenting it out, but no change. >> Assam, where would the parentheses go? I've fiddled with it but dont know >> where. This is the block of code that i assume you are referring to: >> XMonad.Actions.Volume >> infixl 1 <* >> (<*) :: Monad m => m a -> m b -> m a >> pa <* pb = pa >>= \a -> pb >> return a >> >> Thanks again >> Dave >> >> >> On Fri, Apr 10, 2015 at 12:35 AM, adam vogt wrote: >> >>> Hi. >>> >>> The fixity is different (infixl 1 not infixl 4) so using the one from >>> control.applicative means some parentheses have to be added. >>> >>> Regards, >>> Assam >>> On Apr 10, 2015 12:16 AM, "Carlos L?pez-Camey" wrote: >>> >>>> Hi Dave, by the results of hoogle *, it looks like (<*) is defined in >>>> Applicative. I think Applicative is a super class of Monad in newer GHC and >>>> is now included in the Prelude. So, I believe it would be safe to just >>>> remove it. >>>> >>>> * >>>> https://www.haskell.org/hoogle/?hoogle=Monad+m+%3D%3E+m+a+-%3E+m+b+-%3E+m+a >>>> >>>> Cheers >>>> >>>> 2015-04-09 21:55 GMT-06:00 Dave Macias : >>>> >>>>> Thanks for responding Brent. >>>>> >>>>> Not very good at haskell myself. >>>>> Im looking at the XMonad.Actions.Volume and there i find: >>>>> >>>>> infixl 1 <* >>>>> (<*) :: Monad m => m a -> m b -> m a >>>>> pa <* pb = pa >>= \a -> pb >> return a >>>>> >>>>> I'm assuming this is what you were referring to for solution (1). I've >>>>> been trying to play with it but i get mixed errors when building, how do i >>>>> rename? >>>>> Here is the code just in case im looking at it wrong: >>>>> >>>>> https://hackage.haskell.org/package/xmonad-extras-0.12/src/XMonad/Actions/Volume.hs >>>>> >>>>> I also plan to email the maintainer, but i would like to have this work >>>>> for educational purposes. >>>>> >>>>> Thanks, >>>>> Dave >>>>> >>>>> On Thu, Apr 9, 2015 at 10:04 AM, Brent Yorgey >>>>> wrote: >>>>> >>>>>> It looks like XMonad.Actions.Volume defines an operator (<*), but as >>>>>> of base-4.8 an operator with that name has been added to the Prelude. The >>>>>> fix would be to either (1) rename the operator in XMonad.Actions.Volume, or >>>>>> (2) hide the operator from Prelude and tell everyone who wants to use >>>>>> XMonad.Actions.Volume.(<*) that they need to hide it from Prelude too. >>>>>> >>>>>> xmonad-extras is not officially a part of the xmonad project; you >>>>>> should contact the maintainers listed at >>>>>> http://hackage.haskell.org/package/xmonad-extras . >>>>>> >>>>>> -Brent >>>>>> >>>>>> On Mon, Apr 6, 2015 at 11:45 PM Dave Macias wrote: >>>>>> >>>>>>> This is my first time posting here so i hope im doing this right. >>>>>>> Just updated ghc to 7.10.1 and had to rebuild xmonad, xmonad-contrib, >>>>>>> and xmobar. >>>>>>> I also use xmonad-extras but it failed during the build. I tried >>>>>>> using cabal and also from source but both give same output: >>>>>>> >>>>>>> $ cabal install xmonad-extras >>>>>>> >>>>>>> Resolving dependencies... >>>>>>> Configuring xmonad-extras-0.12... >>>>>>> Building xmonad-extras-0.12... >>>>>>> Failed to install xmonad-extras-0.12 >>>>>>> Build log ( /home/dvmacias/.cabal/logs/xmonad-extras-0.12.log ): >>>>>>> Configuring xmonad-extras-0.12... >>>>>>> Building xmonad-extras-0.12... >>>>>>> Preprocessing library xmonad-extras-0.12... >>>>>>> [1 of 2] Compiling XMonad.Util.WindowPropertiesRE ( >>>>>>> XMonad/Util/WindowPropertiesRE.hs, >>>>>>> dist/build/XMonad/Util/WindowPropertiesRE.o ) >>>>>>> [2 of 2] Compiling XMonad.Actions.Volume ( XMonad/Actions/Volume.hs, >>>>>>> dist/build/XMonad/Actions/Volume.o ) >>>>>>> >>>>>>> XMonad/Actions/Volume.hs:173:23: >>>>>>> Ambiguous occurrence ?<*? >>>>>>> It could refer to either ?XMonad.Actions.Volume.<*?, >>>>>>> defined at XMonad/Actions/Volume.hs:66:4 >>>>>>> or ?Prelude.<*?, >>>>>>> imported from ?Prelude? at >>>>>>> XMonad/Actions/Volume.hs:15:8-28 >>>>>>> (and originally defined in ?GHC.Base?) >>>>>>> >>>>>>> XMonad/Actions/Volume.hs:173:43: >>>>>>> Ambiguous occurrence ?<*? >>>>>>> It could refer to either ?XMonad.Actions.Volume.<*?, >>>>>>> defined at XMonad/Actions/Volume.hs:66:4 >>>>>>> or ?Prelude.<*?, >>>>>>> imported from ?Prelude? at >>>>>>> XMonad/Actions/Volume.hs:15:8-28 >>>>>>> (and originally defined in ?GHC.Base?) >>>>>>> >>>>>>> XMonad/Actions/Volume.hs:200:62: >>>>>>> Ambiguous occurrence ?<*? >>>>>>> It could refer to either ?XMonad.Actions.Volume.<*?, >>>>>>> defined at XMonad/Actions/Volume.hs:66:4 >>>>>>> or ?Prelude.<*?, >>>>>>> imported from ?Prelude? at >>>>>>> XMonad/Actions/Volume.hs:15:8-28 >>>>>>> (and originally defined in ?GHC.Base?) >>>>>>> >>>>>>> XMonad/Actions/Volume.hs:215:32: >>>>>>> Ambiguous occurrence ?<*? >>>>>>> It could refer to either ?XMonad.Actions.Volume.<*?, >>>>>>> defined at XMonad/Actions/Volume.hs:66:4 >>>>>>> or ?Prelude.<*?, >>>>>>> imported from ?Prelude? at >>>>>>> XMonad/Actions/Volume.hs:15:8-28 >>>>>>> (and originally defined in ?GHC.Base?) >>>>>>> >>>>>>> XMonad/Actions/Volume.hs:225:58: >>>>>>> Ambiguous occurrence ?<*? >>>>>>> >>>>>>> It could refer to either ?XMonad.Actions.Volume.<*?, >>>>>>> defined at XMonad/Actions/Volume.hs:66:4 >>>>>>> or ?Prelude.<*?, >>>>>>> imported from ?Prelude? at >>>>>>> XMonad/Actions/Volume.hs:15:8-28 >>>>>>> (and originally defined in ?GHC.Base?) >>>>>>> cabal: Error: some packages failed to install: >>>>>>> xmonad-extras-0.12 failed during the building phase. The exception >>>>>>> was: >>>>>>> ExitFailure 1 >>>>>>> >>>>>>> >>>>>>> I got to look at the log but it just has what i pasted above. System >>>>>>> is Arch 3.19.2-1-ARCH >>>>>>> >>>>>>> Any input is appreciated. >>>>>>> Thanks >>>>>>> dave >>>>>>> _______________________________________________ >>>>>>> xmonad mailing list >>>>>>> xmonad at haskell.org >>>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad >>>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> xmonad mailing list >>>>> xmonad at haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> xmonad mailing list >>>> xmonad at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad >>>> >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From byorgey at gmail.com Wed Apr 15 13:18:18 2015 From: byorgey at gmail.com (Brent Yorgey) Date: Wed, 15 Apr 2015 13:18:18 +0000 Subject: [xmonad] Two patches related to XMonad.Prompt In-Reply-To: References: Message-ID: OK, I've made some progress figuring out what is going on. In short: the searchPredicate field is never used in XMonad.Prompt! The only place the searchPredicate is used is in XMonad.Prompt.Window, in the definition of the doPrompt function. So this will work if you happen to be using a prompt to pick a window, but not for any other sort of prompt. This actually seems like a bug in XMonad.Prompt. At some point someone added a searchPredicate field to the XPConfig, but forgot to actually use it to filter completion results. Norbert, is this something you could look into? I've looked through XMonad.Prompt briefly but not sure where the right place is for this to go. I'll probably get around to it eventually if no one else does. -Brent On Fri, Apr 3, 2015 at 6:08 PM Brent Yorgey wrote: > Hmm, I tried it out but can't seem to get it to work. Mysterious. The > patches are definitely applied, my xmonad.hs includes definitions for > sorter and searchPredicate, it compiles cleanly, but when I open a prompt > it has the same behavior as before. > > I'll try to spend some more time tracking down what is going on but just > wanted to briefly report. > > -Brent > > On Mon, Mar 23, 2015 at 2:39 PM Brent Yorgey wrote: > >> >> >> ---------- Forwarded message --------- >> From: Norbert Zeh >> Date: 12:59pm, Sat, Mar 14, 2015 >> Subject: [xmonad] Two patches related to XMonad.Prompt >> To: xmonad at haskell.org >> >> >> Hi folks, >> >> I really got used to using emacs ido mode, which offers a pretty powerful >> and intuitive fuzzy matching of completions, so I wanted to port the same >> to XMonad.Prompt. This required two patches, included in the attached >> patch bundles: >> >> (1) Completions should be sortable by how well they match the current >> query string. This turned out to be a very easy addition of a 'sorter' >> function to XPConfig, which is parameterized by the current query string. >> The default is 'const id', that is, no sorting is done, which is exactly >> the old behaviour of XMonad.Prompt. >> >> (2) A new module XMonad.Prompt.FuzzyMatch that implements the fuzzy >> matching. The exact rules for matching and sorting of matches are >> explained in its documentation. >> >> As usual, let me know if anything needs to straightened out before these >> patches can be applied. >> >> Cheers, >> Norbert >> _______________________________________________ >> xmonad mailing list >> xmonad at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nzeh at cs.dal.ca Wed Apr 15 13:45:52 2015 From: nzeh at cs.dal.ca (Norbert Zeh) Date: Wed, 15 Apr 2015 13:45:52 +0000 Subject: [xmonad] Two patches related to XMonad.Prompt In-Reply-To: References: Message-ID: I also noticed that some prompts don't use the searchPredicate. In my setup, I'm using the fuzzy matching for matching windows, Thunar bookmarks, and xrandr settings. The first of course already uses searchPredicate and the latter two are custom prompts in my xmonad.hs that I wrote to use searchPredicate. X.P.Shell is a particular example that does not use searchPredicate, if I recall correctly. All specific instantiations of X.Prompt essentially decide individually how to define the completion function passed to mkXPrompt. I think most existing prompts can be rewritten to use searchPredicate, but this of course doesn't prevent anybody from writing new prompt instances that don't use it. One (bad) possibility to prevent this would be to change mkXPrompt so that the "completion function" it accepts is not actually a completion function that depends on the search string but simply a function that generates all candidates to be filtered using searchPredicate. That's a bad idea, though, because (a) it breaks the current API and thus any setup that includes custom prompts like mine and (b) it is possible that there are cases where generating all possible candidates and then filtering matches is impossible or prohibitively expensive while generating candidate completions based on the current query string is possible and efficient (e.g., a prompt to list the top 10 matches of a Google search). Cheers, Norbert On Wed, Apr 15, 2015 at 10:18 AM Brent Yorgey wrote: > OK, I've made some progress figuring out what is going on. In short: the > searchPredicate field is never used in XMonad.Prompt! The only place the > searchPredicate is used is in XMonad.Prompt.Window, in the definition of > the doPrompt function. So this will work if you happen to be using a > prompt to pick a window, but not for any other sort of prompt. > > This actually seems like a bug in XMonad.Prompt. At some point someone > added a searchPredicate field to the XPConfig, but forgot to actually use > it to filter completion results. > > Norbert, is this something you could look into? I've looked through > XMonad.Prompt briefly but not sure where the right place is for this to > go. I'll probably get around to it eventually if no one else does. > > -Brent > > On Fri, Apr 3, 2015 at 6:08 PM Brent Yorgey wrote: > >> Hmm, I tried it out but can't seem to get it to work. Mysterious. The >> patches are definitely applied, my xmonad.hs includes definitions for >> sorter and searchPredicate, it compiles cleanly, but when I open a prompt >> it has the same behavior as before. >> >> I'll try to spend some more time tracking down what is going on but just >> wanted to briefly report. >> >> -Brent >> >> On Mon, Mar 23, 2015 at 2:39 PM Brent Yorgey wrote: >> >>> >>> >>> ---------- Forwarded message --------- >>> From: Norbert Zeh >>> Date: 12:59pm, Sat, Mar 14, 2015 >>> Subject: [xmonad] Two patches related to XMonad.Prompt >>> To: xmonad at haskell.org >>> >>> >>> Hi folks, >>> >>> I really got used to using emacs ido mode, which offers a pretty >>> powerful and intuitive fuzzy matching of completions, so I wanted to port >>> the same to XMonad.Prompt. This required two patches, included in the >>> attached patch bundles: >>> >>> (1) Completions should be sortable by how well they match the current >>> query string. This turned out to be a very easy addition of a 'sorter' >>> function to XPConfig, which is parameterized by the current query string. >>> The default is 'const id', that is, no sorting is done, which is exactly >>> the old behaviour of XMonad.Prompt. >>> >>> (2) A new module XMonad.Prompt.FuzzyMatch that implements the fuzzy >>> matching. The exact rules for matching and sorting of matches are >>> explained in its documentation. >>> >>> As usual, let me know if anything needs to straightened out before these >>> patches can be applied. >>> >>> Cheers, >>> Norbert >>> >> _______________________________________________ >>> xmonad mailing list >>> xmonad at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad >>> >> _______________________________________________ > xmonad mailing list > xmonad at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad > -------------- next part -------------- An HTML attachment was scrubbed... URL: From byorgey at gmail.com Wed Apr 15 16:57:05 2015 From: byorgey at gmail.com (Brent Yorgey) Date: Wed, 15 Apr 2015 16:57:05 +0000 Subject: [xmonad] Two patches related to XMonad.Prompt In-Reply-To: References: Message-ID: Ah, I see. In that case I am not sure what a good solution is. It is not just that "some prompts don't use the searchPredicate". In fact, XMonad.Prompt.Window is the *only* prompt that uses it! (based on grepping the entire source tree of xmonad-contrib.) I do understand your points about not running searchPredicate on the output of the completion function. So I wonder if we should add searchPredicate to some of the other existing prompts in xmonad-contrib. For example, it seems strange that XMonad.Prompt.Window uses it but XMonad.Prompt.Workspace does not. But no matter what this seems like an unfortunate situation; it seems to me there is no way to prevent users from being surprised when they set their searchPredicate and some prompts are affected but others are not. At the very least we would want to add some prominent warnings to the documentation of searchPredicate and XMonad.Prompt.FuzzyMatch. -Brent On Wed, Apr 15, 2015 at 9:46 AM Norbert Zeh wrote: > I also noticed that some prompts don't use the searchPredicate. In my > setup, I'm using the fuzzy matching for matching windows, Thunar bookmarks, > and xrandr settings. The first of course already uses searchPredicate and > the latter two are custom prompts in my xmonad.hs that I wrote to use > searchPredicate. > > X.P.Shell is a particular example that does not use searchPredicate, if I > recall correctly. All specific instantiations of X.Prompt essentially > decide individually how to define the completion function passed to > mkXPrompt. I think most existing prompts can be rewritten to use > searchPredicate, but this of course doesn't prevent anybody from writing > new prompt instances that don't use it. One (bad) possibility to prevent > this would be to change mkXPrompt so that the "completion function" it > accepts is not actually a completion function that depends on the search > string but simply a function that generates all candidates to be filtered > using searchPredicate. That's a bad idea, though, because (a) it breaks > the current API and thus any setup that includes custom prompts like mine > and (b) it is possible that there are cases where generating all possible > candidates and then filtering matches is impossible or prohibitively > expensive while generating candidate completions based on the current query > string is possible and efficient (e.g., a prompt to list the top 10 matches > of a Google search). > > Cheers, > Norbert > > > On Wed, Apr 15, 2015 at 10:18 AM Brent Yorgey wrote: > >> OK, I've made some progress figuring out what is going on. In short: the >> searchPredicate field is never used in XMonad.Prompt! The only place the >> searchPredicate is used is in XMonad.Prompt.Window, in the definition of >> the doPrompt function. So this will work if you happen to be using a >> prompt to pick a window, but not for any other sort of prompt. >> >> This actually seems like a bug in XMonad.Prompt. At some point someone >> added a searchPredicate field to the XPConfig, but forgot to actually use >> it to filter completion results. >> >> Norbert, is this something you could look into? I've looked through >> XMonad.Prompt briefly but not sure where the right place is for this to >> go. I'll probably get around to it eventually if no one else does. >> >> -Brent >> >> On Fri, Apr 3, 2015 at 6:08 PM Brent Yorgey wrote: >> >>> Hmm, I tried it out but can't seem to get it to work. Mysterious. The >>> patches are definitely applied, my xmonad.hs includes definitions for >>> sorter and searchPredicate, it compiles cleanly, but when I open a prompt >>> it has the same behavior as before. >>> >>> I'll try to spend some more time tracking down what is going on but just >>> wanted to briefly report. >>> >>> -Brent >>> >>> On Mon, Mar 23, 2015 at 2:39 PM Brent Yorgey wrote: >>> >>>> >>>> >>>> ---------- Forwarded message --------- >>>> From: Norbert Zeh >>>> Date: 12:59pm, Sat, Mar 14, 2015 >>>> Subject: [xmonad] Two patches related to XMonad.Prompt >>>> To: xmonad at haskell.org >>>> >>>> >>>> Hi folks, >>>> >>>> I really got used to using emacs ido mode, which offers a pretty >>>> powerful and intuitive fuzzy matching of completions, so I wanted to port >>>> the same to XMonad.Prompt. This required two patches, included in the >>>> attached patch bundles: >>>> >>>> (1) Completions should be sortable by how well they match the current >>>> query string. This turned out to be a very easy addition of a 'sorter' >>>> function to XPConfig, which is parameterized by the current query string. >>>> The default is 'const id', that is, no sorting is done, which is exactly >>>> the old behaviour of XMonad.Prompt. >>>> >>>> (2) A new module XMonad.Prompt.FuzzyMatch that implements the fuzzy >>>> matching. The exact rules for matching and sorting of matches are >>>> explained in its documentation. >>>> >>>> As usual, let me know if anything needs to straightened out before >>>> these patches can be applied. >>>> >>>> Cheers, >>>> Norbert >>>> >>> _______________________________________________ >>>> xmonad mailing list >>>> xmonad at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad >>>> >>> _______________________________________________ >> xmonad mailing list >> xmonad at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad >> > _______________________________________________ > xmonad mailing list > xmonad at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad > -------------- next part -------------- An HTML attachment was scrubbed... URL: From byorgey at gmail.com Wed Apr 15 17:14:45 2015 From: byorgey at gmail.com (Brent Yorgey) Date: Wed, 15 Apr 2015 17:14:45 +0000 Subject: [xmonad] xmonad: xmonad-extras 0.12 fails to build In-Reply-To: <1429046465598.63a4581@Nodemailer> References: <1429046465598.63a4581@Nodemailer> Message-ID: Did you actually open a ticket on the issue tracker? Or just send a message to the mailing list? If the latter, there's nothing more you need to do. -Brent On Tue, Apr 14, 2015 at 5:21 PM wrote: > Looks like maintainer updated the package. > Do i have to do anything to close this? > > Thanks all for support > Dave > > ? > Sent from iPhone > > > On Tue, Apr 14, 2015 at 2:24 PM, adam vogt wrote: > >> I mean an expression like: >> >> > headerLine >> playbackChannels >>= volumes <* eof >> >> needs parentheses like: >> >> (headerLine >> playbackChannels >>= volumes) <* eof >> >> if we were to use the inflxl 4 <* >> >> On Tue, Apr 14, 2015 at 8:15 AM, Dave Macias wrote: >> >>> Thank you all for the replies. >>> I've tried removing it by simply commenting it out, but no change. >>> Assam, where would the parentheses go? I've fiddled with it but dont >>> know where. This is the block of code that i assume you are referring to: >>> XMonad.Actions.Volume >>> infixl 1 <* >>> (<*) :: Monad m => m a -> m b -> m a >>> pa <* pb = pa >>= \a -> pb >> return a >>> >>> Thanks again >>> Dave >>> >>> >>> On Fri, Apr 10, 2015 at 12:35 AM, adam vogt wrote: >>> >>>> Hi. >>>> >>>> The fixity is different (infixl 1 not infixl 4) so using the one from >>>> control.applicative means some parentheses have to be added. >>>> >>>> Regards, >>>> Assam >>>> On Apr 10, 2015 12:16 AM, "Carlos L?pez-Camey" >>>> wrote: >>>> >>>>> Hi Dave, by the results of hoogle *, it looks like (<*) is defined in >>>>> Applicative. I think Applicative is a super class of Monad in newer GHC and >>>>> is now included in the Prelude. So, I believe it would be safe to just >>>>> remove it. >>>>> >>>>> * >>>>> https://www.haskell.org/hoogle/?hoogle=Monad+m+%3D%3E+m+a+-%3E+m+b+-%3E+m+a >>>>> >>>>> Cheers >>>>> >>>>> 2015-04-09 21:55 GMT-06:00 Dave Macias : >>>>> >>>>>> Thanks for responding Brent. >>>>>> >>>>>> Not very good at haskell myself. >>>>>> Im looking at the XMonad.Actions.Volume and there i find: >>>>>> >>>>>> infixl 1 <* >>>>>> (<*) :: Monad m => m a -> m b -> m a >>>>>> pa <* pb = pa >>= \a -> pb >> return a >>>>>> >>>>>> I'm assuming this is what you were referring to for solution (1). >>>>>> I've been trying to play with it but i get mixed errors when building, how >>>>>> do i rename? >>>>>> Here is the code just in case im looking at it wrong: >>>>>> >>>>>> https://hackage.haskell.org/package/xmonad-extras-0.12/src/XMonad/Actions/Volume.hs >>>>>> >>>>>> I also plan to email the maintainer, but i would like to have this >>>>>> work for educational purposes. >>>>>> >>>>>> Thanks, >>>>>> Dave >>>>>> >>>>>> On Thu, Apr 9, 2015 at 10:04 AM, Brent Yorgey >>>>>> wrote: >>>>>> >>>>>>> It looks like XMonad.Actions.Volume defines an operator (<*), but >>>>>>> as of base-4.8 an operator with that name has been added to the Prelude. >>>>>>> The fix would be to either (1) rename the operator in >>>>>>> XMonad.Actions.Volume, or (2) hide the operator from Prelude and tell >>>>>>> everyone who wants to use XMonad.Actions.Volume.(<*) that they need to hide >>>>>>> it from Prelude too. >>>>>>> >>>>>>> xmonad-extras is not officially a part of the xmonad project; you >>>>>>> should contact the maintainers listed at >>>>>>> http://hackage.haskell.org/package/xmonad-extras . >>>>>>> >>>>>>> -Brent >>>>>>> >>>>>>> On Mon, Apr 6, 2015 at 11:45 PM Dave Macias >>>>>>> wrote: >>>>>>> >>>>>>>> This is my first time posting here so i hope im doing this right. >>>>>>>> Just updated ghc to 7.10.1 and had to rebuild xmonad, >>>>>>>> xmonad-contrib, and xmobar. >>>>>>>> I also use xmonad-extras but it failed during the build. I tried >>>>>>>> using cabal and also from source but both give same output: >>>>>>>> >>>>>>>> $ cabal install xmonad-extras >>>>>>>> >>>>>>>> Resolving dependencies... >>>>>>>> Configuring xmonad-extras-0.12... >>>>>>>> Building xmonad-extras-0.12... >>>>>>>> Failed to install xmonad-extras-0.12 >>>>>>>> Build log ( /home/dvmacias/.cabal/logs/xmonad-extras-0.12.log ): >>>>>>>> Configuring xmonad-extras-0.12... >>>>>>>> Building xmonad-extras-0.12... >>>>>>>> Preprocessing library xmonad-extras-0.12... >>>>>>>> [1 of 2] Compiling XMonad.Util.WindowPropertiesRE ( >>>>>>>> XMonad/Util/WindowPropertiesRE.hs, >>>>>>>> dist/build/XMonad/Util/WindowPropertiesRE.o ) >>>>>>>> [2 of 2] Compiling XMonad.Actions.Volume ( >>>>>>>> XMonad/Actions/Volume.hs, dist/build/XMonad/Actions/Volume.o ) >>>>>>>> >>>>>>>> XMonad/Actions/Volume.hs:173:23: >>>>>>>> Ambiguous occurrence ?<*? >>>>>>>> It could refer to either ?XMonad.Actions.Volume.<*?, >>>>>>>> defined at >>>>>>>> XMonad/Actions/Volume.hs:66:4 >>>>>>>> or ?Prelude.<*?, >>>>>>>> imported from ?Prelude? at >>>>>>>> XMonad/Actions/Volume.hs:15:8-28 >>>>>>>> (and originally defined in ?GHC.Base?) >>>>>>>> >>>>>>>> XMonad/Actions/Volume.hs:173:43: >>>>>>>> Ambiguous occurrence ?<*? >>>>>>>> It could refer to either ?XMonad.Actions.Volume.<*?, >>>>>>>> defined at >>>>>>>> XMonad/Actions/Volume.hs:66:4 >>>>>>>> or ?Prelude.<*?, >>>>>>>> imported from ?Prelude? at >>>>>>>> XMonad/Actions/Volume.hs:15:8-28 >>>>>>>> (and originally defined in ?GHC.Base?) >>>>>>>> >>>>>>>> XMonad/Actions/Volume.hs:200:62: >>>>>>>> Ambiguous occurrence ?<*? >>>>>>>> It could refer to either ?XMonad.Actions.Volume.<*?, >>>>>>>> defined at >>>>>>>> XMonad/Actions/Volume.hs:66:4 >>>>>>>> or ?Prelude.<*?, >>>>>>>> imported from ?Prelude? at >>>>>>>> XMonad/Actions/Volume.hs:15:8-28 >>>>>>>> (and originally defined in ?GHC.Base?) >>>>>>>> >>>>>>>> XMonad/Actions/Volume.hs:215:32: >>>>>>>> Ambiguous occurrence ?<*? >>>>>>>> It could refer to either ?XMonad.Actions.Volume.<*?, >>>>>>>> defined at >>>>>>>> XMonad/Actions/Volume.hs:66:4 >>>>>>>> or ?Prelude.<*?, >>>>>>>> imported from ?Prelude? at >>>>>>>> XMonad/Actions/Volume.hs:15:8-28 >>>>>>>> (and originally defined in ?GHC.Base?) >>>>>>>> >>>>>>>> XMonad/Actions/Volume.hs:225:58: >>>>>>>> Ambiguous occurrence ?<*? >>>>>>>> >>>>>>>> It could refer to either ?XMonad.Actions.Volume.<*?, >>>>>>>> defined at >>>>>>>> XMonad/Actions/Volume.hs:66:4 >>>>>>>> or ?Prelude.<*?, >>>>>>>> imported from ?Prelude? at >>>>>>>> XMonad/Actions/Volume.hs:15:8-28 >>>>>>>> (and originally defined in ?GHC.Base?) >>>>>>>> cabal: Error: some packages failed to install: >>>>>>>> xmonad-extras-0.12 failed during the building phase. The exception >>>>>>>> was: >>>>>>>> ExitFailure 1 >>>>>>>> >>>>>>>> >>>>>>>> I got to look at the log but it just has what i pasted above. >>>>>>>> System is Arch 3.19.2-1-ARCH >>>>>>>> >>>>>>>> Any input is appreciated. >>>>>>>> Thanks >>>>>>>> dave >>>>>>>> _______________________________________________ >>>>>>>> xmonad mailing list >>>>>>>> xmonad at haskell.org >>>>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad >>>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> xmonad mailing list >>>>>> xmonad at haskell.org >>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> xmonad mailing list >>>>> xmonad at haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad >>>>> >>>>> >>> >> > _______________________________________________ > xmonad mailing list > xmonad at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davama at gmail.com Wed Apr 15 19:46:12 2015 From: davama at gmail.com (davama at gmail.com) Date: Wed, 15 Apr 2015 12:46:12 -0700 (PDT) Subject: [xmonad] xmonad: xmonad-extras 0.12 fails to build In-Reply-To: References: Message-ID: <1429127171962.2173465e@Nodemailer> I just sent an email. Thanks! Dave ? Sent from iPhone On Wed, Apr 15, 2015 at 1:14 PM, Brent Yorgey wrote: > Did you actually open a ticket on the issue tracker? Or just send a > message to the mailing list? If the latter, there's nothing more you need > to do. > -Brent > On Tue, Apr 14, 2015 at 5:21 PM wrote: >> Looks like maintainer updated the package. >> Do i have to do anything to close this? >> >> Thanks all for support >> Dave >> >> ? >> Sent from iPhone >> >> >> On Tue, Apr 14, 2015 at 2:24 PM, adam vogt wrote: >> >>> I mean an expression like: >>> >>> > headerLine >> playbackChannels >>= volumes <* eof >>> >>> needs parentheses like: >>> >>> (headerLine >> playbackChannels >>= volumes) <* eof >>> >>> if we were to use the inflxl 4 <* >>> >>> On Tue, Apr 14, 2015 at 8:15 AM, Dave Macias wrote: >>> >>>> Thank you all for the replies. >>>> I've tried removing it by simply commenting it out, but no change. >>>> Assam, where would the parentheses go? I've fiddled with it but dont >>>> know where. This is the block of code that i assume you are referring to: >>>> XMonad.Actions.Volume >>>> infixl 1 <* >>>> (<*) :: Monad m => m a -> m b -> m a >>>> pa <* pb = pa >>= \a -> pb >> return a >>>> >>>> Thanks again >>>> Dave >>>> >>>> >>>> On Fri, Apr 10, 2015 at 12:35 AM, adam vogt wrote: >>>> >>>>> Hi. >>>>> >>>>> The fixity is different (infixl 1 not infixl 4) so using the one from >>>>> control.applicative means some parentheses have to be added. >>>>> >>>>> Regards, >>>>> Assam >>>>> On Apr 10, 2015 12:16 AM, "Carlos L?pez-Camey" >>>>> wrote: >>>>> >>>>>> Hi Dave, by the results of hoogle *, it looks like (<*) is defined in >>>>>> Applicative. I think Applicative is a super class of Monad in newer GHC and >>>>>> is now included in the Prelude. So, I believe it would be safe to just >>>>>> remove it. >>>>>> >>>>>> * >>>>>> https://www.haskell.org/hoogle/?hoogle=Monad+m+%3D%3E+m+a+-%3E+m+b+-%3E+m+a >>>>>> >>>>>> Cheers >>>>>> >>>>>> 2015-04-09 21:55 GMT-06:00 Dave Macias : >>>>>> >>>>>>> Thanks for responding Brent. >>>>>>> >>>>>>> Not very good at haskell myself. >>>>>>> Im looking at the XMonad.Actions.Volume and there i find: >>>>>>> >>>>>>> infixl 1 <* >>>>>>> (<*) :: Monad m => m a -> m b -> m a >>>>>>> pa <* pb = pa >>= \a -> pb >> return a >>>>>>> >>>>>>> I'm assuming this is what you were referring to for solution (1). >>>>>>> I've been trying to play with it but i get mixed errors when building, how >>>>>>> do i rename? >>>>>>> Here is the code just in case im looking at it wrong: >>>>>>> >>>>>>> https://hackage.haskell.org/package/xmonad-extras-0.12/src/XMonad/Actions/Volume.hs >>>>>>> >>>>>>> I also plan to email the maintainer, but i would like to have this >>>>>>> work for educational purposes. >>>>>>> >>>>>>> Thanks, >>>>>>> Dave >>>>>>> >>>>>>> On Thu, Apr 9, 2015 at 10:04 AM, Brent Yorgey >>>>>>> wrote: >>>>>>> >>>>>>>> It looks like XMonad.Actions.Volume defines an operator (<*), but >>>>>>>> as of base-4.8 an operator with that name has been added to the Prelude. >>>>>>>> The fix would be to either (1) rename the operator in >>>>>>>> XMonad.Actions.Volume, or (2) hide the operator from Prelude and tell >>>>>>>> everyone who wants to use XMonad.Actions.Volume.(<*) that they need to hide >>>>>>>> it from Prelude too. >>>>>>>> >>>>>>>> xmonad-extras is not officially a part of the xmonad project; you >>>>>>>> should contact the maintainers listed at >>>>>>>> http://hackage.haskell.org/package/xmonad-extras . >>>>>>>> >>>>>>>> -Brent >>>>>>>> >>>>>>>> On Mon, Apr 6, 2015 at 11:45 PM Dave Macias >>>>>>>> wrote: >>>>>>>> >>>>>>>>> This is my first time posting here so i hope im doing this right. >>>>>>>>> Just updated ghc to 7.10.1 and had to rebuild xmonad, >>>>>>>>> xmonad-contrib, and xmobar. >>>>>>>>> I also use xmonad-extras but it failed during the build. I tried >>>>>>>>> using cabal and also from source but both give same output: >>>>>>>>> >>>>>>>>> $ cabal install xmonad-extras >>>>>>>>> >>>>>>>>> Resolving dependencies... >>>>>>>>> Configuring xmonad-extras-0.12... >>>>>>>>> Building xmonad-extras-0.12... >>>>>>>>> Failed to install xmonad-extras-0.12 >>>>>>>>> Build log ( /home/dvmacias/.cabal/logs/xmonad-extras-0.12.log ): >>>>>>>>> Configuring xmonad-extras-0.12... >>>>>>>>> Building xmonad-extras-0.12... >>>>>>>>> Preprocessing library xmonad-extras-0.12... >>>>>>>>> [1 of 2] Compiling XMonad.Util.WindowPropertiesRE ( >>>>>>>>> XMonad/Util/WindowPropertiesRE.hs, >>>>>>>>> dist/build/XMonad/Util/WindowPropertiesRE.o ) >>>>>>>>> [2 of 2] Compiling XMonad.Actions.Volume ( >>>>>>>>> XMonad/Actions/Volume.hs, dist/build/XMonad/Actions/Volume.o ) >>>>>>>>> >>>>>>>>> XMonad/Actions/Volume.hs:173:23: >>>>>>>>> Ambiguous occurrence ?<*? >>>>>>>>> It could refer to either ?XMonad.Actions.Volume.<*?, >>>>>>>>> defined at >>>>>>>>> XMonad/Actions/Volume.hs:66:4 >>>>>>>>> or ?Prelude.<*?, >>>>>>>>> imported from ?Prelude? at >>>>>>>>> XMonad/Actions/Volume.hs:15:8-28 >>>>>>>>> (and originally defined in ?GHC.Base?) >>>>>>>>> >>>>>>>>> XMonad/Actions/Volume.hs:173:43: >>>>>>>>> Ambiguous occurrence ?<*? >>>>>>>>> It could refer to either ?XMonad.Actions.Volume.<*?, >>>>>>>>> defined at >>>>>>>>> XMonad/Actions/Volume.hs:66:4 >>>>>>>>> or ?Prelude.<*?, >>>>>>>>> imported from ?Prelude? at >>>>>>>>> XMonad/Actions/Volume.hs:15:8-28 >>>>>>>>> (and originally defined in ?GHC.Base?) >>>>>>>>> >>>>>>>>> XMonad/Actions/Volume.hs:200:62: >>>>>>>>> Ambiguous occurrence ?<*? >>>>>>>>> It could refer to either ?XMonad.Actions.Volume.<*?, >>>>>>>>> defined at >>>>>>>>> XMonad/Actions/Volume.hs:66:4 >>>>>>>>> or ?Prelude.<*?, >>>>>>>>> imported from ?Prelude? at >>>>>>>>> XMonad/Actions/Volume.hs:15:8-28 >>>>>>>>> (and originally defined in ?GHC.Base?) >>>>>>>>> >>>>>>>>> XMonad/Actions/Volume.hs:215:32: >>>>>>>>> Ambiguous occurrence ?<*? >>>>>>>>> It could refer to either ?XMonad.Actions.Volume.<*?, >>>>>>>>> defined at >>>>>>>>> XMonad/Actions/Volume.hs:66:4 >>>>>>>>> or ?Prelude.<*?, >>>>>>>>> imported from ?Prelude? at >>>>>>>>> XMonad/Actions/Volume.hs:15:8-28 >>>>>>>>> (and originally defined in ?GHC.Base?) >>>>>>>>> >>>>>>>>> XMonad/Actions/Volume.hs:225:58: >>>>>>>>> Ambiguous occurrence ?<*? >>>>>>>>> >>>>>>>>> It could refer to either ?XMonad.Actions.Volume.<*?, >>>>>>>>> defined at >>>>>>>>> XMonad/Actions/Volume.hs:66:4 >>>>>>>>> or ?Prelude.<*?, >>>>>>>>> imported from ?Prelude? at >>>>>>>>> XMonad/Actions/Volume.hs:15:8-28 >>>>>>>>> (and originally defined in ?GHC.Base?) >>>>>>>>> cabal: Error: some packages failed to install: >>>>>>>>> xmonad-extras-0.12 failed during the building phase. The exception >>>>>>>>> was: >>>>>>>>> ExitFailure 1 >>>>>>>>> >>>>>>>>> >>>>>>>>> I got to look at the log but it just has what i pasted above. >>>>>>>>> System is Arch 3.19.2-1-ARCH >>>>>>>>> >>>>>>>>> Any input is appreciated. >>>>>>>>> Thanks >>>>>>>>> dave >>>>>>>>> _______________________________________________ >>>>>>>>> xmonad mailing list >>>>>>>>> xmonad at haskell.org >>>>>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> xmonad mailing list >>>>>>> xmonad at haskell.org >>>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> xmonad mailing list >>>>>> xmonad at haskell.org >>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad >>>>>> >>>>>> >>>> >>> >> _______________________________________________ >> xmonad mailing list >> xmonad at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From codesite-noreply at google.com Thu Apr 16 13:11:16 2015 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Thu, 16 Apr 2015 13:11:16 +0000 Subject: [xmonad] Issue 602 in xmonad: xmonad hangs when clickJustFocuses = False and the user clicks outside of the focused window while a submap is active. Message-ID: <0-3425899027203913298-11954270657760967272-codesite-noreply=google.com@googlecode.com> Status: New Owner: ---- New issue 602 by untfu... at gmail.com: xmonad hangs when clickJustFocuses = False and the user clicks outside of the focused window while a submap is active. https://code.google.com/p/xmonad/issues/detail?id=602 What steps will reproduce the problem? 1. Set clickJustFocuses = False 2. Activate a submap or submapDefault (XMonad.Actions.Submap) 3. Click outside of the currently focused window. What is the expected output? I'm not sure if expected output is defined, but when clickJustFocuses = True, any clicks are ignored until after the submap is exited, after which the focus is brought to the most recently clicked window. Ideally, one might be able to specify that a click aborts the submap, instead, or to specify a submap action resulting from a click. What do you see instead? XMonad hangs irrecoverably. Keybindings and clicks have no effect whatsoever. Any programs active in the background (e.g. music) continue as without user input. Please use labels and text to provide additional information. I have attached a minimal xfce config (I have not tested this outside of xfce) that reproduces the error. The steps for reproducing are: 1. Mod+l (activates testSubmap) 2. Click outside of the currently focused window Remarks: the error also occurs if testSubmap is made into an empty map. Attachments: xfce_xmonad.hs 1.1 KB -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings From codesite-noreply at google.com Thu Apr 16 13:56:14 2015 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Thu, 16 Apr 2015 13:56:14 +0000 Subject: [xmonad] Issue 599 in xmonad: documentation on building xmonad is missing In-Reply-To: <1-3425899027203913298-17944620313692417879-codesite-noreply=google.com@googlecode.com> References: <1-3425899027203913298-17944620313692417879-codesite-noreply=google.com@googlecode.com> <0-3425899027203913298-17944620313692417879-codesite-noreply=google.com@googlecode.com> Message-ID: <2-3425899027203913298-17944620313692417879-codesite-noreply=google.com@googlecode.com> Updates: Status: Accepted Comment #2 on issue 599 by byor... at gmail.com: documentation on building xmonad is missing https://code.google.com/p/xmonad/issues/detail?id=599 You're right, some instructions do seem to be missing. Where is the source of the xmonad website hosted these days? -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings From auke at tulcod.com Thu Apr 16 21:30:17 2015 From: auke at tulcod.com (Auke Booij) Date: Thu, 16 Apr 2015 23:30:17 +0200 Subject: [xmonad] WaylandMonad In-Reply-To: References: Message-ID: Would this currently be considered an unrealistic project, or a project not worth investing time in? I should probably add that the wayland API is considered stable. It is certainly stable enough for GNOME, KDE, enlightenment, and numerous other window managers to be in active development (and very far, at that). The key "xdg-shell" protocol is still under development, but for the (technically rather limited) use case of WaylandMonad, no substantial changes are being introduced. On 14 April 2015 at 14:41, Auke Booij wrote: > A few weeks ago, I sent in a Google Summer of Code application for the > haskell.org organization to work on porting Xmonad to wayland. The > haskell organization has asked me to find a mentor for my application, > which is the main reason for this email. > > If you are > 1. an adult (sorry kids, Google's rules) > 2. experienced with the Xmonad source > 3. interested in wayland > 4. willing to spend some time this summer on mentoring me > then please contact me or someone in the haskell community to discuss > mentoring options. The deadline for proposal matching is the 24th of > April, so please contact me within this week (or better yet, as soon > as possible). > > Without a mentor, I cannot get accepted for GSoC. I am already up to > speed on wayland, so I think any Xmonad developer with some free time > would make a great mentor. > > I attached my GSoC application below. > > Any comment on making Xmonad work on wayland is welcome as well. My > current plan is to fork Xmonad and replace all the X bits by wayland > bits - see also my proposal below. > > Greetings, > Auke. > > > Abstract > === > XMonad has, for a long time, been a flagship product of the Haskell > community. With the arrival of wayland, XMonad is bound to look stuck > in the past, and it's time for a port. Thanks to my previous work on > wayland-related haskell libraries, this is now a viable project. > > Proposal > === > > Background > --- > X11 has long been the de facto standard way for applications to > display graphical user interfaces on the screen. For various reasons, > a new project called wayland has been started, that can be seen as a > successor of the X ecosystem, or at least can be seen as something > that will play a very important role. Among others, GNOME is already > working on wayland support, and plans to make it fully supported by > version 3.18. This shows the relevance of wayland. > > XMonad is a flagship product of the Haskell community that is often > cited as an example of the applicability of Haskell: its real world > value. XMonad is a compositor (aka window manager) for the X11 > ecosystem. > > In the new wayland ecosystem, one cannot reuse X11 compositors: they > need to be partially rewritten. > > Goal > --- > I intend to fork XMonad and make it into a wayland compositor. Since > the general ideas behind the X11 and the wayland protocol are not too > different, this should be doable: we are still working with pointers > and windows and input and output and renderings and messages. However, > the wayland setup is technically very different from X11, since the > central X11 server has been replaced by the compositor itself, and > this means some very foundational code will need to be rewritten. > > I am the author of hayland [1], the haskell bindings to the wayland C > library, as well as haskell-xkbcommon [2], the haskell bindings to the > xkbcommon C library. With these two projects in place, the time is > ripe for a wayland compositor written in haskell: the preliminaries > are mostly there. > > As part of this project, I will have to invest some time in these two > bindings projects as well (since they are quite new and have had > little testing). For this reason, I intend to keep the scope of this > project limited, and focus on getting some version of XMonad running > on Wayland. > > I do not intend to change the architecture of XMonad, except wherever > this would not require much more investment of time, and only as > wished by the community. In other words: if you have anything that I > should change about XMonad, and it is easy to switch to this new > thing, then I'll use it. Any serious architectural changes will need > to take place in a later stage. > > Deliverables > --- > - A working wayland compositor written in wayland, based on XMonad > - Documentation of the source code (i.e. a technical document), user > documentation (where this differs from XMonad) > - Roadmap for further work: how should this project be continued into > a next iteration of the XMonad project? > > Roadmap > --- > April/May: properly work my way through the XMonad source, and > document things that will need changing > > June: Hack until it's working > > June+July: More hacking, also documentation > > August: Prepare a proper release, clean up code > > Bio > --- > I am currently studying for a Master of Logic in Amsterdam, and have a > Master of Advanced Studies in Mathematics from Cambridge, UK, a BSc in > Applied Mathematics and a BSc in Electrical Engineering (both from TU > Delft). > > I have previously successfully finished GSoC (2010, with Gentoo) and > SOCIS (in 2013, with PyBRML) (SOCIS is a GSoC-like program managed by > the European Space Agency). > > I am the author of hayland [1], the haskell bindings to the wayland C > library, as well as haskell-xkbcommon [2], the haskell bindings to the > xkbcommon C library. > > > > The name of this fork is up for discussion. > > [1] https://github.com/tulcod/haskell-wayland > > [2] https://github.com/tulcod/haskell-xkbcommon From carstenmattner at gmail.com Fri Apr 17 14:03:04 2015 From: carstenmattner at gmail.com (Carsten Mattner) Date: Fri, 17 Apr 2015 16:03:04 +0200 Subject: [xmonad] WaylandMonad In-Reply-To: References: Message-ID: Sounds like a good project to me and I'd like to see the results. On Thu, Apr 16, 2015 at 11:30 PM, Auke Booij wrote: > Would this currently be considered an unrealistic project, or a > project not worth investing time in? > > I should probably add that the wayland API is considered stable. It is > certainly stable enough for GNOME, KDE, enlightenment, and numerous > other window managers to be in active development (and very far, at > that). The key "xdg-shell" protocol is still under development, but > for the (technically rather limited) use case of WaylandMonad, no > substantial changes are being introduced. > > On 14 April 2015 at 14:41, Auke Booij wrote: >> A few weeks ago, I sent in a Google Summer of Code application for the >> haskell.org organization to work on porting Xmonad to wayland. The >> haskell organization has asked me to find a mentor for my application, >> which is the main reason for this email. >> >> If you are >> 1. an adult (sorry kids, Google's rules) >> 2. experienced with the Xmonad source >> 3. interested in wayland >> 4. willing to spend some time this summer on mentoring me >> then please contact me or someone in the haskell community to discuss >> mentoring options. The deadline for proposal matching is the 24th of >> April, so please contact me within this week (or better yet, as soon >> as possible). >> >> Without a mentor, I cannot get accepted for GSoC. I am already up to >> speed on wayland, so I think any Xmonad developer with some free time >> would make a great mentor. >> >> I attached my GSoC application below. >> >> Any comment on making Xmonad work on wayland is welcome as well. My >> current plan is to fork Xmonad and replace all the X bits by wayland >> bits - see also my proposal below. >> >> Greetings, >> Auke. >> >> >> Abstract >> === >> XMonad has, for a long time, been a flagship product of the Haskell >> community. With the arrival of wayland, XMonad is bound to look stuck >> in the past, and it's time for a port. Thanks to my previous work on >> wayland-related haskell libraries, this is now a viable project. >> >> Proposal >> === >> >> Background >> --- >> X11 has long been the de facto standard way for applications to >> display graphical user interfaces on the screen. For various reasons, >> a new project called wayland has been started, that can be seen as a >> successor of the X ecosystem, or at least can be seen as something >> that will play a very important role. Among others, GNOME is already >> working on wayland support, and plans to make it fully supported by >> version 3.18. This shows the relevance of wayland. >> >> XMonad is a flagship product of the Haskell community that is often >> cited as an example of the applicability of Haskell: its real world >> value. XMonad is a compositor (aka window manager) for the X11 >> ecosystem. >> >> In the new wayland ecosystem, one cannot reuse X11 compositors: they >> need to be partially rewritten. >> >> Goal >> --- >> I intend to fork XMonad and make it into a wayland compositor. Since >> the general ideas behind the X11 and the wayland protocol are not too >> different, this should be doable: we are still working with pointers >> and windows and input and output and renderings and messages. However, >> the wayland setup is technically very different from X11, since the >> central X11 server has been replaced by the compositor itself, and >> this means some very foundational code will need to be rewritten. >> >> I am the author of hayland [1], the haskell bindings to the wayland C >> library, as well as haskell-xkbcommon [2], the haskell bindings to the >> xkbcommon C library. With these two projects in place, the time is >> ripe for a wayland compositor written in haskell: the preliminaries >> are mostly there. >> >> As part of this project, I will have to invest some time in these two >> bindings projects as well (since they are quite new and have had >> little testing). For this reason, I intend to keep the scope of this >> project limited, and focus on getting some version of XMonad running >> on Wayland. >> >> I do not intend to change the architecture of XMonad, except wherever >> this would not require much more investment of time, and only as >> wished by the community. In other words: if you have anything that I >> should change about XMonad, and it is easy to switch to this new >> thing, then I'll use it. Any serious architectural changes will need >> to take place in a later stage. >> >> Deliverables >> --- >> - A working wayland compositor written in wayland, based on XMonad >> - Documentation of the source code (i.e. a technical document), user >> documentation (where this differs from XMonad) >> - Roadmap for further work: how should this project be continued into >> a next iteration of the XMonad project? >> >> Roadmap >> --- >> April/May: properly work my way through the XMonad source, and >> document things that will need changing >> >> June: Hack until it's working >> >> June+July: More hacking, also documentation >> >> August: Prepare a proper release, clean up code >> >> Bio >> --- >> I am currently studying for a Master of Logic in Amsterdam, and have a >> Master of Advanced Studies in Mathematics from Cambridge, UK, a BSc in >> Applied Mathematics and a BSc in Electrical Engineering (both from TU >> Delft). >> >> I have previously successfully finished GSoC (2010, with Gentoo) and >> SOCIS (in 2013, with PyBRML) (SOCIS is a GSoC-like program managed by >> the European Space Agency). >> >> I am the author of hayland [1], the haskell bindings to the wayland C >> library, as well as haskell-xkbcommon [2], the haskell bindings to the >> xkbcommon C library. >> >> >> >> The name of this fork is up for discussion. >> >> [1] https://github.com/tulcod/haskell-wayland >> >> [2] https://github.com/tulcod/haskell-xkbcommon > _______________________________________________ > xmonad mailing list > xmonad at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad From steve at thestever.net Fri Apr 17 15:53:28 2015 From: steve at thestever.net (Steve Quezadas) Date: Fri, 17 Apr 2015 08:53:28 -0700 Subject: [xmonad] xmonad with emacs In-Reply-To: References: <552D4EE0.2090903@thestever.net> <552D5F8E.3010406@thestever.net> Message-ID: <55312C78.2090609@thestever.net> Ok, I found out the conflict that I thought was attributable to xmonad. As a reminder, "control-space" is a keybinding under emacs for the set-mark-command feature which allows a user to select text. For some reason, control-space wasn't working when emacs was under x-monad, but was working when it was using Ubuntu unity. Actually, the conflict over the keybinding happened with ibus. ibus somehow maps control-space and prevents emacs from using that key command. When I disabled ibus, the problem stopped. so it wasn't xmonad's fault. I am putting this on the maillist just in case other people have this problem, they can look it up through keywords or whatever. - Steve PS I really LOVE x-monad. It's so much more efficient with larger monitors. Keep up the good work guys! > Yes; I was looking for what you just told me, that you were using Unity > which presumably loads a keymap. (I have no idea which one, though.) > xmonad will be using the server default. > > Unfortunately, control expansions are special-cased in both xkb and > xmodmap and can't be specified --- which makes me wonder how you managed > to lose it, unless the real problem is whatever terminal emulator you're > getting (given gnomeConfig, presumably gnome-terminal) was handling it > itself, and has different settings when not running in a Gnome 3 > session. (You cannot use xmonad, or any window manager that is not a > Gnome Shell derivative (gnome-shell, or the Unity or Cinnamon forks > thereof), with Gnome 3. This is not something we have any control over.) > > MATE's fork of gnome-terminal does the right thing under xmonad --- but > I am using a MATE session (since it's a fork of Gnome 2, it still allows > alternative window managers). I also don't see a way to control it from > its preferences or keyboard shortcuts. Gnome 3's gnome-terminal may > differ, though. From joe9mail at gmail.com Fri Apr 17 19:33:23 2015 From: joe9mail at gmail.com (Joe M) Date: Fri, 17 Apr 2015 15:33:23 -0400 Subject: [xmonad] [patch] Dynamic window property matching In-Reply-To: References: Message-ID: <20150417193322.GA25395@master> Thanks, Now I can get my browser windows to move to a particular workspace. Brandon Allbery wrote: > 1 patch for repository http://code.haskell.org/XMonadContrib: > > Fri Apr 10 15:34:49 EDT 2015 allbery.b at gmail.com > * dynamicproperty > Run a ManageHook from handleEventHook when a window property changes. > You would use this to match e.g. browser windows whose title is not > "final" until after the on-load hooks of the loaded document complete. > > > New patches: > > [dynamicproperty > allbery.b at gmail.com**20150410193449 > Ignore-this: 7f58cbd7fadeffa96a3b635d14a51d4b > Run a ManageHook from handleEventHook when a window property changes. > You would use this to match e.g. browser windows whose title is not > "final" until after the on-load hooks of the loaded document complete. > ] { > addfile ./XMonad/Hooks/DynamicProperty.hs > hunk ./XMonad/Hooks/DynamicProperty.hs 1 > +----------------------------------------------------------------------------- > +-- | > +-- Module : XMonad.Hooks.DynamicProperty > +-- Copyright : (c) Brandon S Allbery, 2014 > +-- License : BSD3-style (see LICENSE) > +-- > +-- Maintainer : allbery.b at gmail.com > +-- Stability : unstable > +-- Portability : not portable > +-- > +-- Module to apply a ManageHook to an already-mapped window when a property > +-- changes. This would commonly be used to match browser windows by title, > +-- since the final title will only be set after (a) the window is mapped, > +-- (b) its document has been loaded, (c) all load-time scripts have run. > +-- (Don't blame browsers for this; it's inherent in HTML and the DOM. And > +-- changing title dynamically is explicitly permitted by ICCCM and EWMH; > +-- you don't really want to have your editor window umapped/remapped to > +-- show the current document and modified state in the titlebar, do you?) > +-- > +-- This is a handleEventHook that triggers on a PropertyChange event. It > +-- currently ignores properties being removed, in part because you can't > +-- do anything useful in a ManageHook involving nonexistence of a property. > +-- > +----------------------------------------------------------------------------- > + > +module XMonad.Hooks.DynamicProperty where > + > +import XMonad > +import Data.Monoid > +import Control.Applicative > +import Control.Monad (when) > + > +-- | > +-- Run a 'ManageHook' when a specific property is changed on a window. Note > +-- that this will run on any window which changes the property, so you > should > +-- be very specific in your 'MansgeHook' matching (lots of windows change > +-- their titles on the fly!): > +-- > +-- dynamicPropertyChange "WM_NAME" (className =? "Iceweasel" <&&> title =? > "whatever" --> doShift "2") > +-- > +-- Note that the fixity of (-->) won't allow it to be mixed with ($), so > you > +-- can't use the obvious $ shorthand. > +-- > +-- > dynamicPropertyChange "WM_NAME" $ title =? "Foo" --> doFloat -- won't > work! > +-- > +-- Consider instead phrasing it like any > +-- other 'ManageHook': > +-- > +-- > , handleEventHook = dynamicPropertyChange "WM_NAME" myDynHook > <+> handleEventHook baseConfig > +-- > > +-- > {- ... -} > +-- > > +-- > myDynHook = composeAll [...] > +-- > +dynamicPropertyChange :: String -> ManageHook -> Event -> X All > +dynamicPropertyChange prop hook PropertyEvent { ev_window = w, ev_atom = > a, ev_propstate = ps } = do > + pa <- getAtom prop > + when (ps == propertyNewValue && a == pa) $ do > + g <- appEndo <$> userCodeDef (Endo id) (runQuery hook w) > + windows g > + return (All False) -- so anything else also processes it > + > +-- | A shorthand for the most common case, dynamic titles > +dynamicTitle :: ManageHook -> Event -> X All > +-- strictly, this should also check _NET_WM_NAME. practically, both will > +-- change and each gets its own PropertyEvent, so we'd need to record that > +-- we saw the event for that window and ignore the second one. Instead, > just > +-- trust that nobody sets only _NET_WM_NAME. (I'm sure this will prove > false, > +-- since there's always someone who can't bother being compliant.) > +dynamicTitle = dynamicPropertyChange "WM_NAME" > hunk ./xmonad-contrib.cabal 167 > XMonad.Hooks.DynamicBars > XMonad.Hooks.DynamicHooks > XMonad.Hooks.DynamicLog > + XMonad.Hooks.DynamicProperty > XMonad.Hooks.DebugStack > XMonad.Hooks.EwmhDesktops > XMonad.Hooks.FadeInactive > } > > Context: > > [minor doc fixes to X.C.Mate > Daniel Wagner **20150330180752 > Ignore-this: f35c2e5068adcf5a04727557078c8a6f > ] > [mate-comment-fixup > allbery.b at gmail.com**20150330160523 > Ignore-this: 687b5edc9220469f3e58abcfd4f6449c > Correct the docstrings / comments in X.C.Mate, which still referenced > gnomeConfig. Also update the session manager configuration to use > dconf and a current (on Mint at least) path for the session config. > ] > [Add the ability to specify padding used with Maximize > Peter Jones **20150309232939 > Ignore-this: 71ac5db4513da0b7a45eb82ec184f4e3 > ] > [Don't restore windows when changing workspaces > Peter Jones **20150310201709 > Ignore-this: 5333205aa1a9fbc5c7844fad69561517 > ] > [New layout modifier: Hidden > Peter Jones **20150309223036 > Ignore-this: 5534fe18e642d1691a9b3f99341e082d > > A layout modifer that is meant to work with the BinarySpacePartition > layout. By removing windows from the window set and adding them back > at a later time, you can move windows to a different branch of the BSP > tree. > > ] > [Fixes to warnings with BSP layout > anton.pirogov at gmail.com**20150315100041 > Ignore-this: 7642710fdb2a866150875f2d521d19fd > ] > [Improved BinarySpacePartition, added Equalize,Balance and FocusParent and > mouse resize support > anton.pirogov at gmail.com**20150312145220 > Ignore-this: 31b5d7bf38e5b391df266906deb5e382 > ] > [New layout module X.L.Dwindle > nzeh at cs.dal.ca**20150315130913 > Ignore-this: a1507e9eda6e6cabd679c2c3b50d9a38 > > This adds three layouts: Spiral is a reimplementation of X.L.Spiral.spiral > with a (to me) more intuitive splitting policy. Dwindle is similar but > pushes > the smaller windows into a corner rather than into the center. Squeeze > just > stacks windows vertically or horizontally using geometrically decreasing > sizes. > ] > [address warnings in P.Pass > Adam Vogt **20150313015636 > Ignore-this: 52e03c09c4d5339085e0306044de8977 > ] > [X.L.AvoidFloats more useful default settings > ankaan at gmail.com**20150310212022 > Ignore-this: af6535bace9219619858751eeeff6520 > Changed default settings with the simple layout modifier. Instead of > asking for a bool indicating if all windows should be avoided, no such bool > is asked for. No windows are avoided by default. I think this will be a > more useful default setting since it would be annoying if dialogue windows > are avoided. The same functionality is possible with the advanced > constructor. This will be easier for new users. > > This will break configurations using the old module, but this will not be > much of an issue since the module has not been added to the repo as of this > writing. > ] > [Resolve minor conflict in xmonad-contrib.cabal > ankaan at gmail.com**20150306175436 > Ignore-this: 24ae68c08107a574199b055989d38347 > ] > [X.L.AvoidFloats, like avoidStruts but for floats > ankaan at gmail.com**20150306171702 > Ignore-this: 3722d7787dd2429313f92f85f3ae1251 > Checks for floating windows within the layout area and finds a maximum area > rectangle within that does not overlap with any of the floating windows. > This rectangle is used for all non-floating windows. > > This new functionality introduced problems with the recommended > configuration > of one of my other modules (X.A.FloatSnap.) A new and more reliable method > of > distinguishing between clicks and drags where therefore introduced in the > new > module X.A.AfterDrag. > > This does not break any prior use of FloatSnap, but will require changes in > configuration if used together with AvoidFloats. (This is mentioned in the > docs for AvoidFloats and I recommend using the new configuration method > even if > AvoidFloats is not in use.) > ] > [X.L.LayoutBuilder place active on top > ankaan at gmail.com**20150306164200 > Ignore-this: 69d718d0d044ee59a877fa0e63edc474 > Make sure that the active layout area is placed on top of all other areas > when placing windows. This makes overlapping areas usable. > ] > [Add rearrangers to X.A.GridSelect > Dmitri Iouchtchenko **20130123044038 > Ignore-this: ef0dc68e9b725953e69e7b039fe06e9a > ] > [Avoid repainting elements in X.A.GridSelect > Dmitri Iouchtchenko **20130123043850 > Ignore-this: 8e926cebc8d458a06a05f7457ae40b68 > ] > [Give a name to the initial state in X.A.GridSelect > Dmitri Iouchtchenko **20130121061324 > Ignore-this: 989ae20ccc3d5b1392f0694d5c62e759 > ] > [Add XMonad.Config.Bepo (Yorick Laupa) > Adam Vogt **20150310214314 > Ignore-this: 71dcf03f9ff80b645531004f95e9c600 > ] > [add instance Default WallpaperConf > Adam Vogt **20150310214246 > Ignore-this: 18e74f249b35726acd4b923ecce3085 > ] > [XMonad.Prompt.Pass: Handle hierachical password stores > Joachim Breitner **20150218091816 > Ignore-this: 2f0a02613780067d324b04a8cdb9c0ed > > pass stores its passwords in directories, so the contents of the directory > store needs to be enumerated recursively. Alexander Sulfrian provided this > patch on the mailinglist, which I tested (it works) and cleaned up > slightly. > > ] > [remove warnings and text dependency from H.WallpaperSetter > Adam Vogt **20150310192933 > Ignore-this: e637d782c13bed48bafbc1458b3f983f > ] > [Added the new hook WallpaperSetter > anton.pirogov at gmail.com**20150228162335 > Ignore-this: 7cbb2ab0d8f9f606f50253deebcf4163 > ] > [adjust an import to fix the build > Adam Vogt **20150310182403 > Ignore-this: 72f67dd2cb1cc6900269383124844c2b > ] > [merge conflicts in X.L.Spacing > Adam Vogt **20150310182046 > Ignore-this: f0830d6483d30d643e7e182e310ec042 > > I should have just applied Anton Pirogov March 4 patch. > ] > [Added messages to adjust the gap dynamically > anton.pirogov at gmail.com**20150304082520 > Ignore-this: 52b590c820db765796de41f38fffdf3c > ] > [X.L.Spacing needs -XPatternGuards now > Adam Vogt **20150310181248 > Ignore-this: d6b2b76fddbd9ad066e7cb39933f055a > ] > [add ConfirmPrompt (Antoine Beaupr?) > Adam Vogt **20150310181036 > Ignore-this: 65d74f05e82c66a3ff4f021d19ceb626 > ] > [Added messages to adjust the gap dynamically > anton.pirogov at gmail.com**20150303210143 > Ignore-this: 891ca1ccca183d6af8e4aa4bf6d843fb > ] > [add another extension to actually fix the build with ghc-7.10-RC1 > Adam Vogt **20150124111939 > Ignore-this: 26d6f1b4cb6d573ccf49e6baeca853e4 > ] > [BinarySpacePartition downstream changes > benweitzman at gmail.com**20141110202259 > Ignore-this: 42ecc2b07388ba0c7b3eac980256c17b > Pulled in changes from my repo for this layout on github ( > https://github.com/benweitzman/BinarySpacePartition) > Includes a new mode for resizing windows in a more intuitive way, also > contains a bug fix that was preventing users from > resiving a window up. > > Includes changes from github users egasimus (Adam Avramov) and > SolitaryCipher (Nick) > > ] > [add XF86AudioMicMute to EZConfig (#582) > Adam Vogt **20141222045306 > Ignore-this: 1c91505b303e53b94da624230b3c893c > ] > [Generalize new workspace addition functions to support arbitrary insertion. > nrujac at gmail.com**20141219002309 > Ignore-this: 9f8c14b5aa9d398b3f167da0af1a8650 > > The current DynamicWorkspaces module only supports adding new workspaces > at the start of the list of workspaces. This means when binding workspaces > to keys based on the position in the list, key bindings can change > as workspaces are added in removed in a far more destructive way than > necessary. Instead, supporting appending and arbitrary insertion allows > the user to determine where the new workspace should be added. > > This patch is a straight generalization of the addHiddenWorkspace' > function. > Rather than always using `(:)` to insert the new workspace into the list > of workspaces, this patches causes it to use an arbitrary list insertion > function instead. A few new functions are added to prevent breakage of > external code while exported functions are left unchanged. > > List of new functions: > appendWorkspace > appendWorkspacePrompt > addWorkspaceAt > addHiddenWorkspaceAt > > Existing functions were modified to call their generalized brethren where > possible > without changing functionality. This patch should not change behavior for > any > existing users of this module. > > ] > [address another bitSize/finiteBitSize warning > Adam Vogt **20141222033300 > Ignore-this: 549e519d25080c77e605dc983f0d239e > ] > [X.L.Master: Add FixMaster layout modifier > Anton Vorontsov **20141220011339 > Ignore-this: 82e9736853287f753248af41843ceb6b > > This layout modifier is useful for the case if you desire to add a master > pane that has fixed width (it's fixed even if there is just one window > opened). Especially nice feature if you don't want to have too wide > terminal in a master pane. > > The layout is implemented as an addition to Master layout, so it reuses > most of the code. > ] > [filepath dependency for P.Pass was left out > Adam Vogt **20141221214129 > Ignore-this: 98e63d7b17ac6ebabd8a6b081f5194a1 > ] > [remove unused imports > Adam Vogt **20140815051234 > Ignore-this: b2e5be31b70e6d31827e76bd8c00d200 > ] > [fix build with ghc-6.12 > Adam Vogt **20140815051214 > Ignore-this: d4c4da527db6c8affc151dc210631b85 > ] > [use FiniteBitSize with ghc >= 7.8 > Adam Vogt **20140815051136 > Ignore-this: 90f855fd72406fb3d2640a133d499188 > ] > [Layout.Spacing: Outer window edges now get as much spacing as inner ones > Felix Crux **20141219223646 > Ignore-this: 61363e97939fe857876c8252ac5f0302 > > Layout.Spacing applies a customizable amount of space around the outside > of each > window. At window edges where two windows meet, the total distance between > them > is therefore twice the customized value (one space value from each > window). At > the edge of the screen, however, the spacing is only applied once. This > results > in uneven amounts of spacing and differently-sized gaps on the screen. > > This patch extends the Spacing layout to include a further gap all around > the > edge of the screen, thus making all spaces around windows equal in size. > > ] > [add filepath package dependency needed by Prompt.Pass > Adam Vogt **20140909145216 > Ignore-this: 588ec76e7fccb4219361da7024c98db4 > > filepath comes with ghc, and it's used by xmonad-core anyways > ] > [X.C.Prime: doc tweaks > Devin Mullins **20141002075939 > Ignore-this: 20d6b829b810f48b5e4b4c161b39b312 > ] > [X.A.Navigation2D: add convenience functions for setting config & > keybindings > Devin Mullins **20141002075757 > Ignore-this: ed01137f03a531f73315ed503d1eb6ef > 1. Added 'additionalNav2DKeys' which adds keybindings for the cartesian > product > of direction keys and (modifier, action) pairs given. > 2. Added 'navigation2D' which combines that with 'withNavigation2DConfig'. > 3. Added 'additionalNav2DKeysP' and 'navigation2DP' which do the same, but > use > the 'additionalKeysP' syntax. > ] > [X.C.Prime: doc fixes > Devin Mullins **20141001075855 > Ignore-this: dbbe00791b04df61dcd595c50333fba > ] > [X.C.Prime: add 'withScreens' and friends > Devin Mullins **20141001075250 > Ignore-this: eba37b1ff3da265a4dcc509f538fce4d > The screen equivalent of 'withWorkspaces' lets you more easily define keys > that > move/swap between screens. > > Also, rename wsKeyspecs to wsKeys, and make a couple of doc tweaks. > ] > [Implement proper handling of dynamically changing hostname > Anton Vorontsov **20140901072158 > Ignore-this: 2aeac6d2161e666d40cda6a09f78b208 > > The module implements a proper way of finding out whether the window is > remote or local. > > Just checking for a hostname and WM_CLIENT_MACHINE being equal is often > not enough because the hostname is a changing subject (without any > established notification mechanisms), and thus WM_CLIENT_MACHINE and the > hostname can diverge even for a local window. > > This module solves the problem. As soon as there is a new window created, > we check the hostname and WM_CLIENT_MACHINE, and then we cache the result > into the XMONAD_REMOTE property. > > Notice that XMonad itself does not know anything about hostnames, nor does > it have any dependency on Network.* modules. For this module it is not a > problem: you can provide a mean to get the hostname through your config > file (see usage). Or, if you don't like the hassle of handling dynamic > hostnames (suppose your hostname never changes), it is also fine: this > module will fallback to using environment variables. > ] > [Add Stoppable layout for power saving > Anton Vorontsov **20140901072141 > Ignore-this: a52805d9f3095cd7af48507847ed2fe3 > > This module implements a special kind of layout modifier, which when > applied to a layout, causes xmonad to stop all non-visible processes. In a > way, this is a sledge-hammer for applications that drain power. For > example, given a web browser on a stoppable workspace, once the workspace > is hidden the web browser will be stopped. > > Note that the stopped application won't be able to communicate with X11 > clipboard. For this, the module actually stops applications after a > certain delay, giving a chance for a user to complete copy-paste sequence. > By default, the delay equals to 15 seconds, it is configurable via > 'Stoppable' constructor. > > The stoppable modifier prepends a mark (by default equals to "Stoppable") > to the layout description (alternatively, you can choose your own mark and > use it with 'Stoppable' constructor). The stoppable layout (identified by > a mark) spans to multiple workspaces, letting you to create groups of > stoppable workspaces that only stop processes when none of the workspaces > are visible, and conversely, unfreezing all processes even if one of the > stoppable workspaces are visible. > > To stop the process we use signals, which works for most cases. For > processes that tinker with signal handling (debuggers), another > (Linux-centric) approach may be used. See > https://www.kernel.org/doc/Documentation/cgroups/freezer-subsystem.txt > ] > [X.C.Prime: doc changes > Devin Mullins **20140925203037 > Ignore-this: 51204c1a9f2e6ed21228d2910417fd21 > ] > [X.C.Prime: add withWorkspaces et al. > Devin Mullins **20140925203034 > Ignore-this: 65f691270110cc5de13c950d9dcb0c17 > This allows easier configuration of workspaces and their keybindings. > Required > generalizing the 'Prime' type, so lots of other lines changed in rather > trivial > ways. > ] > [X.C.Prime: add ifThenElse binding > Devin Mullins **20140924191509 > Ignore-this: ae775c418c27301b9c12d2a233502cec > This is necessary for if-then-else support in the user's config. > ] > [X.C.Prime: doc fixes > Devin Mullins **20140915080601 > Ignore-this: 15e3c445a99d3b2d3a235aa76119797 > ] > [X.C.Prime: fix 'def' hyperlink in doc > Devin Mullins **20140914075352 > Ignore-this: a1de1d81a5f140ab7d90edbf393e9bda > ] > [XMonad.Config.Prime, a do-notation for config > Devin Mullins **20140914064828 > Ignore-this: f7397aa6e6efe5d76acebfa22c567baa > Note that the use of RebindableSyntax is because of the need to vary the > layoutHook type throughout the config. The alternative, using the > existential > Layout type, was rejected because it required TemplateHaskell in order to > look > nice, and TemplateHaskell is not portable. > > I've tried to make a version of (>>) that also worked on normal monads, but > have had no luck as of yet. Maybe some intrepid soul can add it later. > ] > [X.P.Shell: fix doc typo > me at twifkak.com**20130317115516 > Ignore-this: bdd385a9142ed039a917d135e76293fe > ] > [reverse workspaces, so that switching to a dynamic workspace group > restores the focus to the screen that was focused at group creation time > nwfilardo at gmail.com**20140913174118 > Ignore-this: b74c02b1892159694827e35122c2d517 > ] > [add filepath dependency, needed by new X.P.Pass module > me at twifkak.com**20140913070926 > Ignore-this: fec97086c1e66cf8a036265bd1a970a8 > ] > [add-new-xmonad-prompt-pass > eniotna.t at gmail.com**20140829131928 > Ignore-this: 11e85dfe3d24cef88d8d89f4e7b1ec0b > This module provides 3 to ease passwords manipulation > (generate, read, remove): > > - one to lookup passwords in the password-storage. > > - one to generate a password for a given password label that the user > inputs. > > - one to delete a stored password for a given password label that the user > inputs. > > All those prompts benefit from the completion system provided by the > module . > > The password store is setuped through an environment variable > PASSWORD_STORE_DIR. > If this is set, use the content of the variable. > Otherwise, the password store is located on user's home > @$HOME\/.password-store at . > > > Source: > > - The password storage implementation is < > http://git.zx2c4.com/password-store the password-store cli>. > > - Inspired from > ] > [use Data.Map instead of Data.Map.Strict to support containers < 0.5 > Adam Vogt **20140815043141 > Ignore-this: 436d18657d8499f4ce57311e84503d9f > ] > [config-mate > allbery.b at gmail.com**20140803020659 > Ignore-this: d5de258c0a28cd5ba64a59cf37cd480a > Initial support for the Mate desktop environment (http://mate-desktop.org). > Based on existing Gnome 2 support, since Mate is a maintained fork of > Gnome 2. > ] > [debug-managehook > allbery.b at gmail.com**20140803020601 > Ignore-this: 51f9255b496cca79e4a53e274c400ecc > A set of hooks, and convenience combinators, to help with ManageHook > debugging. > Ordinary users may well want to use debugManageHookOn in normal configs, > specifying a key sequence which can be pressed before running a command in > order to capture debug information just for that command's main window. > > This is especially useful when trying to diagnose issues such as programs > that do not play well with SpawnOn, or ManageHook matching on 'title' when > the program does not set the window title until after it is mapped. > ] > [debug-debug > allbery.b at gmail.com**20140803020530 > Ignore-this: cbb2b1d99293e3a4d02a256c2733aeb0 > Various fixes and enhancements to DebugWindow and DebugStack. ManageDebug > requires these fixes, but some of them are significant even if not using > ManageDebug. > ] > [derive Applicative instances to suppress AMP warning > Adam Vogt **20140710163950 > Ignore-this: c2110d07bccc61462c3fbf73c900aaa1 > ] > [clean up cabal file and drop support for base < 3 > Adam Vogt **20140710013255 > Ignore-this: 76b142e2b114604feac9b8e41cf71ab > ] > [add-duck-duck-go-search-engine > eniotna.t at gmail.com**20140617174246 > Ignore-this: 29bbfb2d07d9ddf36bf0268a4e255f81 > ] > [XSelection: getSelection: fix connection exhaustion bug (issue #573); > include warning > gwern at gwern.net**20140601025019 > Ignore-this: add21190fc07338b243c2241cc746119 > ] > [Fix dbus-send call in XMonad.Config.Gnome > md143rbh7f at gmail.com**20140129032114 > Ignore-this: ed62458b55c8b34b77f73027eeee1a73 > dbus-send --print-reply=string is invalid, but it was silently ignored > until recently: > > http://cgit.freedesktop.org/dbus/dbus/commit/tools/dbus-send.c?id=c690ee4351f99ed5e629ffcf5f4a2edcd418d103 > I've changed XMonad.Config.Gnome to run --print-reply=literal, since > that's what the old behavior was. > ] > [warning police (unused variables) > Adam Vogt **20140505001242 > Ignore-this: a15b4d844b1da4f1f1f9b6095c968705 > ] > [This patch makes the Ssh extension works with **user** arguments in ssh, > .e.g ssh admin at localhost. > linxray at gmail.com**20140504091120 > Ignore-this: 297673e11d3049c4f127aac3e172d361 > ] > [remove trailing whitespace in L.BinarySpacePartition > Adam Vogt **20140501011943 > Ignore-this: 8dd677978992e0854801b8f254463dc2 > ] > [replace Bound with the equivalent Direction2D > Adam Vogt **20140501011540 > Ignore-this: b1f1c256aba07f70918fe1d693c8087b > ] > [remove unused extension in BSP > Adam Vogt **20140501011455 > Ignore-this: a4962486b2aa3980536bff19a537451e > ] > [Add BinarySpacePartition layout > benweitzman at gmail.com**20140430205848 > Ignore-this: a85d1dc51bf54c59ae2bd9d948cc1088 > ] > [X.Actions.DynamicWorkspaceGroups: export new function addRawWSGroup > Brent Yorgey **20140428142901 > Ignore-this: a487882c9571bf91ff921d6561bb4cc6 > ] > [Remove unneeded context with the IfMax layout instance > Adam Vogt **20140422221105 > Ignore-this: 3b8ac316f56df6a84420754db769fb0 > > Extra constraints on instances are about as useful as -XDataTypeContexts > ] > [Adding side tabs and replacing TabbarLocation with Direction2D. > nrujac at gmail.com**20140219200811 > Ignore-this: edabeec973b4e0d61515818367689843 > ] > [warning police > Daniel Wagner **20140316183747 > Ignore-this: fd16435ccdd3fee8924723cc690cc239 > ] > [New module: XMonad.Util.WindowState > Dmitry Bogatov **20140218100229 > Ignore-this: 14a6fa263c423cd8cca3b2645b3930d7 > > Save almost arbitary data per window > ] > [Add side tabs to the tabbed layout. > nrujac at gmail.com**20140213215247 > Ignore-this: f81bafe9cb75a30ed6bbbe68cf5d66c0 > ] > [SpawnNamedPipe hlint cleanup > cwills.dev at gmail.com**20140202213613 > Ignore-this: dbb68c4c5522026bd108d0158e747b48 > ] > [document and cleanup SpawnNamedPipe > cwills.dev at gmail.com**20140202211000 > Ignore-this: b264278f1f1ab1f18b37245a5ff33136 > ] > [Added SpawnNamedPipe > cwills.dev at gmail.com**20140202143415 > Ignore-this: 87797ffffc8d0fd088482bd0c5baf0e > ] > [Make commandToComplete in XMonad.Prompt.Shell complete last word > md143rbh7f at gmail.com**20140130200050 > Ignore-this: b0fe22fdd7b9409835fd0ca069f2e01a > > The following change from 2013-02-09 breaks shell completion for me: > hunk ./XMonad/Prompt/Shell.hs 65 > + commandToComplete _ c = c > > It seems to be passing the entire string into compgen in order to get the > file completions, but it should only pass the last word. I propose > reverting this change. Comments are appreciated. > ] > [expose and document X.L.IndependentScreens.marshallSort > Daniel Wagner **20140128212844 > Ignore-this: 90c1437c6ffe1dbd8f4a4ed192097ec > ] > [ServerMode properly indent > Adam Vogt **20131219201440 > Ignore-this: 761b39c3e3c90b6123f068e8b1d34e5d > ] > [remove ServerMode tabs > Adam Vogt **20131219201000 > Ignore-this: f21448c248ec0ac289c309ed964ebcff > ] > [fix -Wall ServerMode > Adam Vogt **20131219181030 > Ignore-this: 708dd5fc60f43dee3d1da085002052f > ] > [documentation note that ServerMode is similar to wmctrl > Adam Vogt **20131219180748 > Ignore-this: 3215bdf1c698c798eca8ed7f62a0f591 > ] > [Generalized XMonad.Hooks.ServerMode > polson2 at hawk.iit.edu**20131216025100 > Ignore-this: e58da3b168a1058f32982833ea25a739 > ] > [IfMax-Layout > Ilya Portnov **20131201072634 > Ignore-this: dac53f2a0505e740f05fdf03f1db0c21 > This adds a new ("conditional") layout, IfMax, which simply runs one > layout, if there are <= N windows, and else runs another layout. > ] > [fix UrgencyHook and add filterUrgencyHook > Adam Vogt **20130924224738 > Ignore-this: 3b7c62275701e6758397977c5c09b744 > ] > [export XMonad.Hooks.UrgencyHook.clearUrgency (issue 533) > Adam Vogt **20130923031349 > Ignore-this: dafe5763d9abcfa606f5c1a8cf5c57d6 > ] > [minor documentation fix: manageDocks doesn't do anything with struts, so > don't claim it does > Daniel Wagner **20130814125106 > Ignore-this: a2610d6c1318ac0977abfc21d1b91632 > ] > [don't pretend to be LG3D in X.C.Dmwit because this confuses modern GTK > Daniel Wagner **20130813211636 > Ignore-this: 8f728dc1b4bf5e472d99419cc5920e51 > ] > [XMonad.Actions.UpdatePointer: generalise updatePointer > Liyang HU **20130730071007 > Ignore-this: 3374a62b6c63dcc152dbf843cd0577f0 > > ] > [XMonad.Actions.UpdatePointer: document TowardsCentre > Liyang HU **20130730053746 > Ignore-this: 2d684b12e4fff0ebec254bea4a4546a3 > > ] > [Haddock formatting in H.Minimize > Adam Vogt **20130723155658 > Ignore-this: 5db3186a51dec58f78954466ded339cb > ] > [Bump version (and xmonad dependency) to 0.12 > Adam Vogt **20130720205857 > Ignore-this: ce165178ca916223501f266339f1de39 > > This makes a breakage due to missing patches in core a bit more obvious. > Previously you would have a build failure regarding some missing > identifiers > (def re-exported by XMonad from Data.Default), while after applying this > patch > it will be clear that xmonad-core needs to be updated. > ] > [Fix issue 551 by also getting manpath without -g flag. > Adam Vogt **20130716030536 > Ignore-this: ded2d51eb7b7697c0fdfaa8158d612df > > Instead of taking Ondrej's approach of figuring out which man (man-db or > http://primates.ximian.com/~flucifredi/man/) is used by the system, just > try > both sets of flags. > ] > [Escape dzen markup and remove xmobar tags from window titles by default. > Adam Vogt **20130708144813 > Ignore-this: cf56bff752fbf78ea06d5c0cb755f615 > > The issue was that window titles, such as those set by, for example a > browser, > could set the window title to display something like > > normal title > > Which could be executed by xmobar (or dzen). > > This adds a ppTitleSanitize which does the above functions. This way when > users > override ppTitle, the benefits are not lost. > > Thanks to Ra?l Benencia and Joachim Breitner for bringing this to my > attention. > ] > [DynamicBars-use-ExtensibleState > gopsychonauts at gmail.com**20130618074755 > Ignore-this: afacba51af2be8ede65b9bcf9b002a7 > > Hooks.DynamicBars was previously using an MVar and the unsafePerformIO > hack ( > http://www.haskell.org/haskellwiki/Top_level_mutable_state ) to store bar > state. Since ExtensibleState exists to solve these sorts of problems, I've > switched the file over to use unsafePerformIO instead. > > Some functions' types had to be changed to allow access to XState, but the > public API is unchanged. > > ] > [Catch exceptions when finding commands on PATH in Prompt.Shell > Thomas Tuegel **20130616230219 > Ignore-this: 5a4d08c80301864bc14ed784f1054c3f > ] > [Fix haddock parse error in X.A.LinkWorkspaces > Adam Vogt **20130528133448 > Ignore-this: 42f05cf8ca9e6d1ffae3bd20666d87ab > ] > [use Data.Default wherever possible, and deprecate the things it replaces > Daniel Wagner **20130528013909 > Ignore-this: 898458b1d2868a70dfb09faf473dc7aa > ] > [eliminate references to defaultConfig > Daniel Wagner **20130528005825 > Ignore-this: 37ae613e4b943e99c5200915b9d95e58 > ] > [minimal change needed to get xmonad-contrib to build with xmonad's > data-default patch > Daniel Wagner **20130528001040 > Ignore-this: 291e4f6cd74fc2b808062e0369665170 > ] > [Remove unneeded XSync call in Layout.ShowWName > Francesco Ariis **20130517153341 > Ignore-this: 4d107c680572eff464c8f6ed9fabdd41 > ] > [Remove misleading comment: we definitely don't support ghc-6.6 anymore > Adam Vogt **20130514215851 > Ignore-this: 2d071cb05709a16763d039222264b426 > ] > [Fix module name in comment of X.L.Fullscreen > Adam Vogt **20130514215727 > Ignore-this: cb5cf18c301c5daf5e1a2527da1ef6bf > ] > [Minor update to cabal file (adding modules & maintainership) > Adam Vogt **20130514215632 > Ignore-this: 82785e02e544e1f797799bed5b5d9be2 > ] > [Remove trailing whitespace in X.A.LinkWorkspaces > Adam Vogt **20130514215421 > Ignore-this: 5015ab4468e7931876eb66b019af804c > ] > [Update documentation of LinkWorkspaces Module > quesel at informatik.uni-oldenburg.de**20110328072813 > Ignore-this: da863534931181f551c9c54bc4076c05 > ] > [Added a module for linking workspaces > quesel at informatik.uni-oldenburg.de**20110210165018 > Ignore-this: 1dba2164cc3387409873d33099596d91 > > This module provides a way to link certain workspaces in a multihead setup. > That way, when switching to the first one the other heads display the > linked > workspaces. > ] > [Cache results from calcGap in ManageDocks > Adam Vogt **20130425155811 > Ignore-this: e5076fdbdfc68bc159424dd4e0f14456 > > http://www.haskell.org/pipermail/xmonad/2013-April/013670.html > ] > [Remove unnecessary contexts from L.MultiToggle > Adam Vogt **20130217163356 > Ignore-this: 6b0e413d8c3a58f62088c32a96c57c51 > ] > [Generalises modWorkspace to take any layout-transforming function > gopsychonauts at gmail.com**20130501151425 > Ignore-this: 28c7dc1f6216bb1ebdffef5434ccbcbd > > modWorkspace already was capable of modifying the layout with an arbitrary > layout -> layout function, but its original type restricted it such that it > could only apply a single LayoutModifier; this was often inconvenient, as > for > example it was not possible simply to compose LayoutModifiers for use with > modWorkspace. > > This patch also reimplements onWorkspaces in terms of modWorkspaces, since > with > the latter's less restrictive type this is now possible. > ] > [since XMonad.Config.Dmwit mentions xmobar, we should include the > associated .xmobarrc file > Daniel Wagner **20130503194055 > Ignore-this: 2f6d7536df81eb767262b79b60eb1b86 > ] > [warning police > Daniel Wagner **20130502012700 > Ignore-this: ae7412ac77c57492a7ad6c5f8f50b9eb > ] > [XMonad.Config.Dmwit > Daniel Wagner **20130502012132 > Ignore-this: 7402161579fd2e191b60a057d955e5ea > ] > [minor fixes to the haddock markup in X.L.IndependentScreens > Daniel Wagner **20130411193849 > Ignore-this: b6a139aa43fdb39fc1b86566c0c34c7a > ] > [add whenCurrentOn to X.L.IndependentScreens > Daniel Wagner **20130408225251 > Ignore-this: ceea3d391f270abc9ed8e52ce19fb1ac > ] > [Allow to specify the initial gaps' states in X.L.Gaps > Paul Fertser **20130222072232 > Ignore-this: 31596d918d0050e36ce3f64f56205a64 > ] > [should bump X11 dependency, too, to make sure we have getAtomName > Daniel Wagner **20130225180527 > Ignore-this: 260711f27551f18cc66afeb7b4846b9f > ] > [getAtomName is now defined in the X11 library > Daniel Wagner **20130225180323 > Ignore-this: 3b9e17c234679e98752a47c37132ee4e > ] > [Allow to limit maximum row count in X.Prompt completion window > Paul Fertser **20130221122050 > Ignore-this: 923656f02996f2de2b1336275392c5f9 > > On a keyboard-less device (such as a smartphone), where one has to use > an on-screen keyboard, the maximum completion window height must be > limited to avoid overlapping the keyboard. > ] > [Note in U.NameActions that xmonad core can list default keys now > Adam Vogt **20130217233026 > Ignore-this: 937bff636fa88171932d5192fe8e290b > ] > [Export U.NamedActions.addDescrKeys per evaryont's request. > Adam Vogt **20130217232619 > Ignore-this: a694a0a3ece70b52fba6e8f688d86344 > ] > [Add EWMH DEMANDS_ATTENTION support to UrgencyHook. > Maarten de Vries **20130212181229 > Ignore-this: 5a4b314d137676758fad9ec8f85ce422 > > Add support for the _NET_WM_STATE_DEMANDS_ATTENTION atom > by treating it the same way as the WM_HINTS urgency flag. > > ] > [Unconditionally set _NET_WORKAREA in ManageDocks > Adam Vogt **20130117180851 > Ignore-this: 9f57e53fba9573d8a92cf153beb7fe7a > ] > [spawn command when no completion is available (if alwaysHighlight is > True); changes commandToComplete in Prompt/Shell to complete the whole word > instead of using getLastWord > c.lopez at kmels.net**20130209190456 > Ignore-this: ca7d354bb301b555b64d5e76e31d10e8 > ] > [order-unindexed-ws-last > matthewhague at zoho.com**20120703222726 > Ignore-this: 4af8162ee8b16a60e8fd62fbc915d3c0 > > Changes the WorkspaceCompare module's comparison by index to put > workspaces without an index last (rather than first). > ] > [SpawnOn modification for issue 523 > Adam Vogt **20130114014642 > Ignore-this: 703f7dc0f800366b752f0ec1cecb52e5 > > This moves the function to help clean up the `Spawner' to the ManageHook > rather than in functions like spawnOn. Probably it makes no difference, the > reason is because there's one manageSpawn function but many different so > this > way there are less functions to write. > ] > [Update L.TrackFloating.useTransient example code > Adam Vogt **20130112041239 > Ignore-this: e4e31cf1db742778c1d59d52fdbeed7a > > Suggest useTransient goes to the right of trackFloating which is the > configuration actually tested. > ] > [Adapt ideas of issue 306 patch to a new modifier in L.TrackFloating > Adam Vogt **20130112035701 > Ignore-this: d54d27b71b97144ef0660f910fd464aa > ] > [Make X.A.CycleWS not rely on hidden WS order > Dmitri Iouchtchenko **20130109023328 > Ignore-this: 8717a154b33253c5df4e9a0ada4c2c3e > ] > [Add X.H.WorkspaceHistory > Dmitri Iouchtchenko **20130109023307 > Ignore-this: c9e7ce33a944facc27481dde52c7cc80 > ] > [Allow removing arbitrary workspaces > Dmitri Iouchtchenko **20121231214343 > Ignore-this: 6fce4bd3d0c5337e5122158583138e74 > ] > [Remove first-hidden restriction from X.A.DynamicWorkspaces.removeWorkspace' > Dmitri Iouchtchenko **20121231214148 > Ignore-this: 55fb0859e9a5f476a834ecbdb774aac8 > ] > [Add authorspellings file for `darcs show authors'. > Adam Vogt **20130101040031 > Ignore-this: c3198072ebc6a71d635bec4d8e2c78fd > > This authorspellings file includes a couple people who've contributed to > xmonad > (not XMonadContrib). When people have multiple addresses, the most recent > one > has been picked. > ] > [TAG 0.11 > Adam Vogt **20130101014231 > Ignore-this: 57cf32412fd1ce912811cb7fafe930f5 > ] > Patch bundle hash: > 670d7e477470a517eb62278dd012400269244bdc > > > -- > brandon s allbery kf8nh sine nomine associates > allbery.b at gmail.com ballbery at sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net > _______________________________________________ > xmonad mailing list > xmonad at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From allbery.b at gmail.com Fri Apr 17 19:40:29 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Fri, 17 Apr 2015 15:40:29 -0400 Subject: [xmonad] [patch] Dynamic window property matching In-Reply-To: <20150417193322.GA25395@master> References: <20150417193322.GA25395@master> Message-ID: On Fri, Apr 17, 2015 at 3:33 PM, Joe M wrote: > Thanks, Now I can get my browser windows to move to a particular workspace. Make sure you get the latest version of it. https://mail.haskell.org/pipermail/xmonad/2015-April/014700.html -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From vogt.adam at gmail.com Fri Apr 17 19:53:11 2015 From: vogt.adam at gmail.com (adam vogt) Date: Fri, 17 Apr 2015 15:53:11 -0400 Subject: [xmonad] trying again: Dynamic properties patch In-Reply-To: References: Message-ID: Thanks Brandon, I've applied this one On Tue, Apr 14, 2015 at 2:41 PM, Brandon Allbery wrote: > As an attachment this time, apparently gmail mangled the previous > attempt(s). > This patch somewhat hackily enables matching things such as browser > windows where the title isn't set properly until "long" after the window is > mapped, because of the way HTML+DOM allows it to be set dynamically by > scripts or etc. > > -- > brandon s allbery kf8nh sine nomine > associates > allbery.b at gmail.com > ballbery at sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > > _______________________________________________ > xmonad mailing list > xmonad at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From crypt17 at gmail.com Fri Apr 17 23:56:24 2015 From: crypt17 at gmail.com (joe skinner) Date: Sat, 18 Apr 2015 11:56:24 +1200 Subject: [xmonad] WaylandMonad In-Reply-To: References: Message-ID: This something that interests me but sadly not something I could help with On Saturday, April 18, 2015, Carsten Mattner wrote: > Sounds like a good project to me and I'd like to see the results. > > On Thu, Apr 16, 2015 at 11:30 PM, Auke Booij > wrote: > > Would this currently be considered an unrealistic project, or a > > project not worth investing time in? > > > > I should probably add that the wayland API is considered stable. It is > > certainly stable enough for GNOME, KDE, enlightenment, and numerous > > other window managers to be in active development (and very far, at > > that). The key "xdg-shell" protocol is still under development, but > > for the (technically rather limited) use case of WaylandMonad, no > > substantial changes are being introduced. > > > > On 14 April 2015 at 14:41, Auke Booij > > wrote: > >> A few weeks ago, I sent in a Google Summer of Code application for the > >> haskell.org organization to work on porting Xmonad to wayland. The > >> haskell organization has asked me to find a mentor for my application, > >> which is the main reason for this email. > >> > >> If you are > >> 1. an adult (sorry kids, Google's rules) > >> 2. experienced with the Xmonad source > >> 3. interested in wayland > >> 4. willing to spend some time this summer on mentoring me > >> then please contact me or someone in the haskell community to discuss > >> mentoring options. The deadline for proposal matching is the 24th of > >> April, so please contact me within this week (or better yet, as soon > >> as possible). > >> > >> Without a mentor, I cannot get accepted for GSoC. I am already up to > >> speed on wayland, so I think any Xmonad developer with some free time > >> would make a great mentor. > >> > >> I attached my GSoC application below. > >> > >> Any comment on making Xmonad work on wayland is welcome as well. My > >> current plan is to fork Xmonad and replace all the X bits by wayland > >> bits - see also my proposal below. > >> > >> Greetings, > >> Auke. > >> > >> > >> Abstract > >> === > >> XMonad has, for a long time, been a flagship product of the Haskell > >> community. With the arrival of wayland, XMonad is bound to look stuck > >> in the past, and it's time for a port. Thanks to my previous work on > >> wayland-related haskell libraries, this is now a viable project. > >> > >> Proposal > >> === > >> > >> Background > >> --- > >> X11 has long been the de facto standard way for applications to > >> display graphical user interfaces on the screen. For various reasons, > >> a new project called wayland has been started, that can be seen as a > >> successor of the X ecosystem, or at least can be seen as something > >> that will play a very important role. Among others, GNOME is already > >> working on wayland support, and plans to make it fully supported by > >> version 3.18. This shows the relevance of wayland. > >> > >> XMonad is a flagship product of the Haskell community that is often > >> cited as an example of the applicability of Haskell: its real world > >> value. XMonad is a compositor (aka window manager) for the X11 > >> ecosystem. > >> > >> In the new wayland ecosystem, one cannot reuse X11 compositors: they > >> need to be partially rewritten. > >> > >> Goal > >> --- > >> I intend to fork XMonad and make it into a wayland compositor. Since > >> the general ideas behind the X11 and the wayland protocol are not too > >> different, this should be doable: we are still working with pointers > >> and windows and input and output and renderings and messages. However, > >> the wayland setup is technically very different from X11, since the > >> central X11 server has been replaced by the compositor itself, and > >> this means some very foundational code will need to be rewritten. > >> > >> I am the author of hayland [1], the haskell bindings to the wayland C > >> library, as well as haskell-xkbcommon [2], the haskell bindings to the > >> xkbcommon C library. With these two projects in place, the time is > >> ripe for a wayland compositor written in haskell: the preliminaries > >> are mostly there. > >> > >> As part of this project, I will have to invest some time in these two > >> bindings projects as well (since they are quite new and have had > >> little testing). For this reason, I intend to keep the scope of this > >> project limited, and focus on getting some version of XMonad running > >> on Wayland. > >> > >> I do not intend to change the architecture of XMonad, except wherever > >> this would not require much more investment of time, and only as > >> wished by the community. In other words: if you have anything that I > >> should change about XMonad, and it is easy to switch to this new > >> thing, then I'll use it. Any serious architectural changes will need > >> to take place in a later stage. > >> > >> Deliverables > >> --- > >> - A working wayland compositor written in wayland, based on XMonad > >> - Documentation of the source code (i.e. a technical document), user > >> documentation (where this differs from XMonad) > >> - Roadmap for further work: how should this project be continued into > >> a next iteration of the XMonad project? > >> > >> Roadmap > >> --- > >> April/May: properly work my way through the XMonad source, and > >> document things that will need changing > >> > >> June: Hack until it's working > >> > >> June+July: More hacking, also documentation > >> > >> August: Prepare a proper release, clean up code > >> > >> Bio > >> --- > >> I am currently studying for a Master of Logic in Amsterdam, and have a > >> Master of Advanced Studies in Mathematics from Cambridge, UK, a BSc in > >> Applied Mathematics and a BSc in Electrical Engineering (both from TU > >> Delft). > >> > >> I have previously successfully finished GSoC (2010, with Gentoo) and > >> SOCIS (in 2013, with PyBRML) (SOCIS is a GSoC-like program managed by > >> the European Space Agency). > >> > >> I am the author of hayland [1], the haskell bindings to the wayland C > >> library, as well as haskell-xkbcommon [2], the haskell bindings to the > >> xkbcommon C library. > >> > >> > >> > >> The name of this fork is up for discussion. > >> > >> [1] https://github.com/tulcod/haskell-wayland > >> > >> [2] https://github.com/tulcod/haskell-xkbcommon > > _______________________________________________ > > xmonad mailing list > > xmonad at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad > _______________________________________________ > xmonad mailing list > xmonad at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nrujac at gmail.com Fri Apr 17 23:57:32 2015 From: nrujac at gmail.com (Arjun Comar) Date: Fri, 17 Apr 2015 19:57:32 -0400 Subject: [xmonad] WaylandMonad In-Reply-To: References: Message-ID: This also interests me, but I'm more of a drive-by contributor than an actual XMonad developer, so I don't know that I'd be a good fit to help get the project approved. On Fri, Apr 17, 2015 at 7:56 PM, joe skinner wrote: > This something that interests me but sadly not something I could help with > > > On Saturday, April 18, 2015, Carsten Mattner > wrote: > >> Sounds like a good project to me and I'd like to see the results. >> >> On Thu, Apr 16, 2015 at 11:30 PM, Auke Booij wrote: >> > Would this currently be considered an unrealistic project, or a >> > project not worth investing time in? >> > >> > I should probably add that the wayland API is considered stable. It is >> > certainly stable enough for GNOME, KDE, enlightenment, and numerous >> > other window managers to be in active development (and very far, at >> > that). The key "xdg-shell" protocol is still under development, but >> > for the (technically rather limited) use case of WaylandMonad, no >> > substantial changes are being introduced. >> > >> > On 14 April 2015 at 14:41, Auke Booij wrote: >> >> A few weeks ago, I sent in a Google Summer of Code application for the >> >> haskell.org organization to work on porting Xmonad to wayland. The >> >> haskell organization has asked me to find a mentor for my application, >> >> which is the main reason for this email. >> >> >> >> If you are >> >> 1. an adult (sorry kids, Google's rules) >> >> 2. experienced with the Xmonad source >> >> 3. interested in wayland >> >> 4. willing to spend some time this summer on mentoring me >> >> then please contact me or someone in the haskell community to discuss >> >> mentoring options. The deadline for proposal matching is the 24th of >> >> April, so please contact me within this week (or better yet, as soon >> >> as possible). >> >> >> >> Without a mentor, I cannot get accepted for GSoC. I am already up to >> >> speed on wayland, so I think any Xmonad developer with some free time >> >> would make a great mentor. >> >> >> >> I attached my GSoC application below. >> >> >> >> Any comment on making Xmonad work on wayland is welcome as well. My >> >> current plan is to fork Xmonad and replace all the X bits by wayland >> >> bits - see also my proposal below. >> >> >> >> Greetings, >> >> Auke. >> >> >> >> >> >> Abstract >> >> === >> >> XMonad has, for a long time, been a flagship product of the Haskell >> >> community. With the arrival of wayland, XMonad is bound to look stuck >> >> in the past, and it's time for a port. Thanks to my previous work on >> >> wayland-related haskell libraries, this is now a viable project. >> >> >> >> Proposal >> >> === >> >> >> >> Background >> >> --- >> >> X11 has long been the de facto standard way for applications to >> >> display graphical user interfaces on the screen. For various reasons, >> >> a new project called wayland has been started, that can be seen as a >> >> successor of the X ecosystem, or at least can be seen as something >> >> that will play a very important role. Among others, GNOME is already >> >> working on wayland support, and plans to make it fully supported by >> >> version 3.18. This shows the relevance of wayland. >> >> >> >> XMonad is a flagship product of the Haskell community that is often >> >> cited as an example of the applicability of Haskell: its real world >> >> value. XMonad is a compositor (aka window manager) for the X11 >> >> ecosystem. >> >> >> >> In the new wayland ecosystem, one cannot reuse X11 compositors: they >> >> need to be partially rewritten. >> >> >> >> Goal >> >> --- >> >> I intend to fork XMonad and make it into a wayland compositor. Since >> >> the general ideas behind the X11 and the wayland protocol are not too >> >> different, this should be doable: we are still working with pointers >> >> and windows and input and output and renderings and messages. However, >> >> the wayland setup is technically very different from X11, since the >> >> central X11 server has been replaced by the compositor itself, and >> >> this means some very foundational code will need to be rewritten. >> >> >> >> I am the author of hayland [1], the haskell bindings to the wayland C >> >> library, as well as haskell-xkbcommon [2], the haskell bindings to the >> >> xkbcommon C library. With these two projects in place, the time is >> >> ripe for a wayland compositor written in haskell: the preliminaries >> >> are mostly there. >> >> >> >> As part of this project, I will have to invest some time in these two >> >> bindings projects as well (since they are quite new and have had >> >> little testing). For this reason, I intend to keep the scope of this >> >> project limited, and focus on getting some version of XMonad running >> >> on Wayland. >> >> >> >> I do not intend to change the architecture of XMonad, except wherever >> >> this would not require much more investment of time, and only as >> >> wished by the community. In other words: if you have anything that I >> >> should change about XMonad, and it is easy to switch to this new >> >> thing, then I'll use it. Any serious architectural changes will need >> >> to take place in a later stage. >> >> >> >> Deliverables >> >> --- >> >> - A working wayland compositor written in wayland, based on XMonad >> >> - Documentation of the source code (i.e. a technical document), user >> >> documentation (where this differs from XMonad) >> >> - Roadmap for further work: how should this project be continued into >> >> a next iteration of the XMonad project? >> >> >> >> Roadmap >> >> --- >> >> April/May: properly work my way through the XMonad source, and >> >> document things that will need changing >> >> >> >> June: Hack until it's working >> >> >> >> June+July: More hacking, also documentation >> >> >> >> August: Prepare a proper release, clean up code >> >> >> >> Bio >> >> --- >> >> I am currently studying for a Master of Logic in Amsterdam, and have a >> >> Master of Advanced Studies in Mathematics from Cambridge, UK, a BSc in >> >> Applied Mathematics and a BSc in Electrical Engineering (both from TU >> >> Delft). >> >> >> >> I have previously successfully finished GSoC (2010, with Gentoo) and >> >> SOCIS (in 2013, with PyBRML) (SOCIS is a GSoC-like program managed by >> >> the European Space Agency). >> >> >> >> I am the author of hayland [1], the haskell bindings to the wayland C >> >> library, as well as haskell-xkbcommon [2], the haskell bindings to the >> >> xkbcommon C library. >> >> >> >> >> >> >> >> The name of this fork is up for discussion. >> >> >> >> [1] https://github.com/tulcod/haskell-wayland >> >> >> >> [2] https://github.com/tulcod/haskell-xkbcommon >> > _______________________________________________ >> > xmonad mailing list >> > xmonad at haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad >> _______________________________________________ >> xmonad mailing list >> xmonad at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad >> > > _______________________________________________ > xmonad mailing list > xmonad at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcin.jan.mrotek at gmail.com Sat Apr 18 07:42:51 2015 From: marcin.jan.mrotek at gmail.com (Marcin Mrotek) Date: Sat, 18 Apr 2015 09:42:51 +0200 Subject: [xmonad] WaylandMonad In-Reply-To: References: Message-ID: For what it's worth I like this idea too, but I'm not a XMonad developer, I just read the list. Best regards, Marcin Mrotek From codesite-noreply at google.com Sat Apr 18 17:17:46 2015 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Sat, 18 Apr 2015 17:17:46 +0000 Subject: [xmonad] Issue 602 in xmonad: xmonad hangs when clickJustFocuses = False and the user clicks outside of the focused window while a submap is active. In-Reply-To: <0-3425899027203913298-11954270657760967272-codesite-noreply=google.com@googlecode.com> References: <0-3425899027203913298-11954270657760967272-codesite-noreply=google.com@googlecode.com> Message-ID: <1-3425899027203913298-11954270657760967272-codesite-noreply=google.com@googlecode.com> Comment #1 on issue 602 by allber... at gmail.com: xmonad hangs when clickJustFocuses = False and the user clicks outside of the focused window while a submap is active. https://code.google.com/p/xmonad/issues/detail?id=602 At a guess, it's using a private event loop instead of the main loop and discarding the messages that would change focus (since it has only a keyboard grab). Either it should grab the pointer to prevent focusing anything else, or it should use the main event loop (via handleEventHook) to recognize keys. (This is unfortunately a common problem with xmonad contribs; most of their authors do not understand X11 event flow, or how events interact, and use na?ve solutions that fail in various circumstances. This is most obviously true with the contribs that manipulate the selection, since the na?ve view thinks a selection is a box that holds content, when it is actually an invitation to an event dialog with the selection holder; but private event loops also tend to show the problem.) -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings From codesite-noreply at google.com Sat Apr 18 17:22:08 2015 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Sat, 18 Apr 2015 17:22:08 +0000 Subject: [xmonad] Issue 602 in xmonad: xmonad hangs when clickJustFocuses = False and the user clicks outside of the focused window while a submap is active. In-Reply-To: <1-3425899027203913298-11954270657760967272-codesite-noreply=google.com@googlecode.com> References: <1-3425899027203913298-11954270657760967272-codesite-noreply=google.com@googlecode.com> <0-3425899027203913298-11954270657760967272-codesite-noreply=google.com@googlecode.com> Message-ID: <2-3425899027203913298-11954270657760967272-codesite-noreply=google.com@googlecode.com> Comment #2 on issue 602 by allber... at gmail.com: xmonad hangs when clickJustFocuses = False and the user clicks outside of the focused window while a submap is active. https://code.google.com/p/xmonad/issues/detail?id=602 Actually, a third possibility is to peekEvent and abort the submap if a non-key event is seen, letting the main loop handle the event. In fact, this is probably closest to the expected behavior. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings From codesite-noreply at google.com Sun Apr 19 21:25:01 2015 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Sun, 19 Apr 2015 21:25:01 +0000 Subject: [xmonad] Issue 597 in xmonad: xmonad-contrib-0.11.4 does not compile In-Reply-To: <1-3425899027203913298-5220352385308706020-codesite-noreply=google.com@googlecode.com> References: <1-3425899027203913298-5220352385308706020-codesite-noreply=google.com@googlecode.com> <0-3425899027203913298-5220352385308706020-codesite-noreply=google.com@googlecode.com> Message-ID: <2-3425899027203913298-5220352385308706020-codesite-noreply=google.com@googlecode.com> Updates: Status: Fixed Comment #2 on issue 597 by daniel.w... at gmail.com: xmonad-contrib-0.11.4 does not compile https://code.google.com/p/xmonad/issues/detail?id=597 This appears to have been fixed since mid-July in darcs by the patch titled "derive Applicative instances to suppress AMP warning". -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings From codesite-noreply at google.com Sun Apr 19 22:07:37 2015 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Sun, 19 Apr 2015 22:07:37 +0000 Subject: [xmonad] Issue 597 in xmonad: xmonad-contrib-0.11.4 does not compile In-Reply-To: <2-3425899027203913298-5220352385308706020-codesite-noreply=google.com@googlecode.com> References: <2-3425899027203913298-5220352385308706020-codesite-noreply=google.com@googlecode.com> <0-3425899027203913298-5220352385308706020-codesite-noreply=google.com@googlecode.com> Message-ID: <3-3425899027203913298-5220352385308706020-codesite-noreply=google.com@googlecode.com> Comment #3 on issue 597 by daniel.w... at gmail.com: xmonad-contrib-0.11.4 does not compile https://code.google.com/p/xmonad/issues/detail?id=597 Issue 601 has been merged into this issue. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings From codesite-noreply at google.com Sun Apr 19 22:08:37 2015 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Sun, 19 Apr 2015 22:08:37 +0000 Subject: [xmonad] Issue 601 in xmonad: xmonad-contrib fails to build with cabal install In-Reply-To: <1-3425899027203913298-12534276130769296481-codesite-noreply=google.com@googlecode.com> References: <1-3425899027203913298-12534276130769296481-codesite-noreply=google.com@googlecode.com> <0-3425899027203913298-12534276130769296481-codesite-noreply=google.com@googlecode.com> Message-ID: <2-3425899027203913298-12534276130769296481-codesite-noreply=google.com@googlecode.com> Updates: Status: Duplicate Mergedinto: 597 Comment #2 on issue 601 by daniel.w... at gmail.com: xmonad-contrib fails to build with cabal install https://code.google.com/p/xmonad/issues/detail?id=601 (No comment was entered for this change.) -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings From codesite-noreply at google.com Sun Apr 19 22:32:52 2015 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Sun, 19 Apr 2015 22:32:52 +0000 Subject: [xmonad] Issue 600 in xmonad: conflicting install instructions In-Reply-To: <2-3425899027203913298-6357311470893718565-codesite-noreply=google.com@googlecode.com> References: <2-3425899027203913298-6357311470893718565-codesite-noreply=google.com@googlecode.com> <0-3425899027203913298-6357311470893718565-codesite-noreply=google.com@googlecode.com> Message-ID: <3-3425899027203913298-6357311470893718565-codesite-noreply=google.com@googlecode.com> Comment #3 on issue 600 by daniel.w... at gmail.com: conflicting install instructions https://code.google.com/p/xmonad/issues/detail?id=600 I would say go ahead and make a pull request. Personally I think it makes more sense to add information to both pages as appropriate to make them consistent than it does to remove information from either. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings From codesite-noreply at google.com Sun Apr 19 22:55:15 2015 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Sun, 19 Apr 2015 22:55:15 +0000 Subject: [xmonad] Issue 599 in xmonad: documentation on building xmonad is missing In-Reply-To: <2-3425899027203913298-17944620313692417879-codesite-noreply=google.com@googlecode.com> References: <2-3425899027203913298-17944620313692417879-codesite-noreply=google.com@googlecode.com> <0-3425899027203913298-17944620313692417879-codesite-noreply=google.com@googlecode.com> Message-ID: <3-3425899027203913298-17944620313692417879-codesite-noreply=google.com@googlecode.com> Comment #3 on issue 599 by daniel.w... at gmail.com: documentation on building xmonad is missing https://code.google.com/p/xmonad/issues/detail?id=599 Changes pushed to github.com/davidlazar/xmonad.org appear on the website relatively frequently (on the order of a few hours). -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings From codesite-noreply at google.com Mon Apr 20 18:11:03 2015 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Mon, 20 Apr 2015 18:11:03 +0000 Subject: [xmonad] Issue 600 in xmonad: conflicting install instructions In-Reply-To: <3-3425899027203913298-6357311470893718565-codesite-noreply=google.com@googlecode.com> References: <3-3425899027203913298-6357311470893718565-codesite-noreply=google.com@googlecode.com> <0-3425899027203913298-6357311470893718565-codesite-noreply=google.com@googlecode.com> Message-ID: <4-3425899027203913298-6357311470893718565-codesite-noreply=google.com@googlecode.com> Comment #4 on issue 600 by byor... at gmail.com: conflicting install instructions https://code.google.com/p/xmonad/issues/detail?id=600 Wait, pull requests? github? The last I knew xmonad uses darcs and is not hosted on github. Did I miss something? I do agree that adding some information to the pages makes sense. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings From codesite-noreply at google.com Mon Apr 20 18:12:03 2015 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Mon, 20 Apr 2015 18:12:03 +0000 Subject: [xmonad] Issue 599 in xmonad: documentation on building xmonad is missing In-Reply-To: <3-3425899027203913298-17944620313692417879-codesite-noreply=google.com@googlecode.com> References: <3-3425899027203913298-17944620313692417879-codesite-noreply=google.com@googlecode.com> <0-3425899027203913298-17944620313692417879-codesite-noreply=google.com@googlecode.com> Message-ID: <4-3425899027203913298-17944620313692417879-codesite-noreply=google.com@googlecode.com> Comment #4 on issue 599 by byor... at gmail.com: documentation on building xmonad is missing https://code.google.com/p/xmonad/issues/detail?id=599 Oh, cool, I didn't know that. Neat. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings From byorgey at gmail.com Thu Apr 23 14:55:43 2015 From: byorgey at gmail.com (Brent Yorgey) Date: Thu, 23 Apr 2015 14:55:43 +0000 Subject: [xmonad] Patch: Re-order XMonad.Hooks.EwmhDesktops hook insertion In-Reply-To: References: Message-ID: This looks sensible. Can you resend it as an actual attachment? I'll be happy to apply it. On Mon, Mar 30, 2015 at 12:18 PM Brandon Allbery wrote: > 1 patch for repository http://code.haskell.org/XMonadContrib: > > Mon Mar 30 12:03:50 EDT 2015 allbery.b at gmail.com > * ewmh-hook-order > Reorder the application of hooks so that users' config is honored. > Notably, this means setWMName works in startupHook instead of > needing to do it repeatedly in logHook. > > New patches: > > [ewmh-hook-order > allbery.b at gmail.com**20150330160350 > Ignore-this: 181a03c890eb541643ff66767f8387a4 > Reorder the application of hooks so that users' config is honored. > Notably, this means setWMName works in startupHook instead of > needing to do it repeatedly in logHook. > ] hunk ./XMonad/Hooks/EwmhDesktops.hs 58 > ewmh c = c { startupHook = startupHook c +++ ewmhDesktopsStartup > , handleEventHook = handleEventHook c +++ ewmhDesktopsEventHook > , logHook = logHook c +++ ewmhDesktopsLogHook } > - where x +++ y = mappend x y > + -- @@@ will fix this correctly later with the rewrite > + where x +++ y = mappend y x > > -- | > -- Initializes EwmhDesktops and advertises EWMH support to the X > > Context: > > [Add the ability to specify padding used with Maximize > Peter Jones **20150309232939 > Ignore-this: 71ac5db4513da0b7a45eb82ec184f4e3 > ] > [Don't restore windows when changing workspaces > Peter Jones **20150310201709 > Ignore-this: 5333205aa1a9fbc5c7844fad69561517 > ] > [New layout modifier: Hidden > Peter Jones **20150309223036 > Ignore-this: 5534fe18e642d1691a9b3f99341e082d > > A layout modifer that is meant to work with the BinarySpacePartition > layout. By removing windows from the window set and adding them back > at a later time, you can move windows to a different branch of the BSP > tree. > > ] > [Fixes to warnings with BSP layout > anton.pirogov at gmail.com**20150315100041 > Ignore-this: 7642710fdb2a866150875f2d521d19fd > ] > [Improved BinarySpacePartition, added Equalize,Balance and FocusParent and > mouse resize support > anton.pirogov at gmail.com**20150312145220 > Ignore-this: 31b5d7bf38e5b391df266906deb5e382 > ] > [New layout module X.L.Dwindle > nzeh at cs.dal.ca**20150315130913 > Ignore-this: a1507e9eda6e6cabd679c2c3b50d9a38 > > This adds three layouts: Spiral is a reimplementation of > X.L.Spiral.spiral > with a (to me) more intuitive splitting policy. Dwindle is similar but > pushes > the smaller windows into a corner rather than into the center. Squeeze > just > stacks windows vertically or horizontally using geometrically decreasing > sizes. > ] > [address warnings in P.Pass > Adam Vogt **20150313015636 > Ignore-this: 52e03c09c4d5339085e0306044de8977 > ] > [X.L.AvoidFloats more useful default settings > ankaan at gmail.com**20150310212022 > Ignore-this: af6535bace9219619858751eeeff6520 > Changed default settings with the simple layout modifier. Instead of > asking for a bool indicating if all windows should be avoided, no such bool > is asked for. No windows are avoided by default. I think this will be a > more useful default setting since it would be annoying if dialogue windows > are avoided. The same functionality is possible with the advanced > constructor. This will be easier for new users. > > This will break configurations using the old module, but this will not be > much of an issue since the module has not been added to the repo as of this > writing. > ] > [Resolve minor conflict in xmonad-contrib.cabal > ankaan at gmail.com**20150306175436 > Ignore-this: 24ae68c08107a574199b055989d38347 > ] > [X.L.AvoidFloats, like avoidStruts but for floats > ankaan at gmail.com**20150306171702 > Ignore-this: 3722d7787dd2429313f92f85f3ae1251 > Checks for floating windows within the layout area and finds a maximum > area > rectangle within that does not overlap with any of the floating windows. > This rectangle is used for all non-floating windows. > > This new functionality introduced problems with the recommended > configuration > of one of my other modules (X.A.FloatSnap.) A new and more reliable > method of > distinguishing between clicks and drags where therefore introduced in the > new > module X.A.AfterDrag. > > This does not break any prior use of FloatSnap, but will require changes > in > configuration if used together with AvoidFloats. (This is mentioned in the > docs for AvoidFloats and I recommend using the new configuration method > even if > AvoidFloats is not in use.) > ] > [X.L.LayoutBuilder place active on top > ankaan at gmail.com**20150306164200 > Ignore-this: 69d718d0d044ee59a877fa0e63edc474 > Make sure that the active layout area is placed on top of all other areas > when placing windows. This makes overlapping areas usable. > ] > [Add rearrangers to X.A.GridSelect > Dmitri Iouchtchenko **20130123044038 > Ignore-this: ef0dc68e9b725953e69e7b039fe06e9a > ] > [Avoid repainting elements in X.A.GridSelect > Dmitri Iouchtchenko **20130123043850 > Ignore-this: 8e926cebc8d458a06a05f7457ae40b68 > ] > [Give a name to the initial state in X.A.GridSelect > Dmitri Iouchtchenko **20130121061324 > Ignore-this: 989ae20ccc3d5b1392f0694d5c62e759 > ] > [Add XMonad.Config.Bepo (Yorick Laupa) > Adam Vogt **20150310214314 > Ignore-this: 71dcf03f9ff80b645531004f95e9c600 > ] > [add instance Default WallpaperConf > Adam Vogt **20150310214246 > Ignore-this: 18e74f249b35726acd4b923ecce3085 > ] > [XMonad.Prompt.Pass: Handle hierachical password stores > Joachim Breitner **20150218091816 > Ignore-this: 2f0a02613780067d324b04a8cdb9c0ed > > pass stores its passwords in directories, so the contents of the directory > store needs to be enumerated recursively. Alexander Sulfrian provided this > patch on the mailinglist, which I tested (it works) and cleaned up > slightly. > > ] > [remove warnings and text dependency from H.WallpaperSetter > Adam Vogt **20150310192933 > Ignore-this: e637d782c13bed48bafbc1458b3f983f > ] > [Added the new hook WallpaperSetter > anton.pirogov at gmail.com**20150228162335 > Ignore-this: 7cbb2ab0d8f9f606f50253deebcf4163 > ] > [adjust an import to fix the build > Adam Vogt **20150310182403 > Ignore-this: 72f67dd2cb1cc6900269383124844c2b > ] > [merge conflicts in X.L.Spacing > Adam Vogt **20150310182046 > Ignore-this: f0830d6483d30d643e7e182e310ec042 > > I should have just applied Anton Pirogov March 4 patch. > ] > [Added messages to adjust the gap dynamically > anton.pirogov at gmail.com**20150304082520 > Ignore-this: 52b590c820db765796de41f38fffdf3c > ] > [X.L.Spacing needs -XPatternGuards now > Adam Vogt **20150310181248 > Ignore-this: d6b2b76fddbd9ad066e7cb39933f055a > ] > [add ConfirmPrompt (Antoine Beaupr?) > Adam Vogt **20150310181036 > Ignore-this: 65d74f05e82c66a3ff4f021d19ceb626 > ] > [Added messages to adjust the gap dynamically > anton.pirogov at gmail.com**20150303210143 > Ignore-this: 891ca1ccca183d6af8e4aa4bf6d843fb > ] > [add another extension to actually fix the build with ghc-7.10-RC1 > Adam Vogt **20150124111939 > Ignore-this: 26d6f1b4cb6d573ccf49e6baeca853e4 > ] > [BinarySpacePartition downstream changes > benweitzman at gmail.com**20141110202259 > Ignore-this: 42ecc2b07388ba0c7b3eac980256c17b > Pulled in changes from my repo for this layout on github ( > https://github.com/benweitzman/BinarySpacePartition) > Includes a new mode for resizing windows in a more intuitive way, also > contains a bug fix that was preventing users from > resiving a window up. > > Includes changes from github users egasimus (Adam Avramov) and > SolitaryCipher (Nick) > > ] > [add XF86AudioMicMute to EZConfig (#582) > Adam Vogt **20141222045306 > Ignore-this: 1c91505b303e53b94da624230b3c893c > ] > [Generalize new workspace addition functions to support arbitrary > insertion. > nrujac at gmail.com**20141219002309 > Ignore-this: 9f8c14b5aa9d398b3f167da0af1a8650 > > The current DynamicWorkspaces module only supports adding new workspaces > at the start of the list of workspaces. This means when binding workspaces > to keys based on the position in the list, key bindings can change > as workspaces are added in removed in a far more destructive way than > necessary. Instead, supporting appending and arbitrary insertion allows > the user to determine where the new workspace should be added. > > This patch is a straight generalization of the addHiddenWorkspace' > function. > Rather than always using `(:)` to insert the new workspace into the list > of workspaces, this patches causes it to use an arbitrary list insertion > function instead. A few new functions are added to prevent breakage of > external code while exported functions are left unchanged. > > List of new functions: > appendWorkspace > appendWorkspacePrompt > addWorkspaceAt > addHiddenWorkspaceAt > > Existing functions were modified to call their generalized brethren where > possible > without changing functionality. This patch should not change behavior for > any > existing users of this module. > > ] > [address another bitSize/finiteBitSize warning > Adam Vogt **20141222033300 > Ignore-this: 549e519d25080c77e605dc983f0d239e > ] > [X.L.Master: Add FixMaster layout modifier > Anton Vorontsov **20141220011339 > Ignore-this: 82e9736853287f753248af41843ceb6b > > This layout modifier is useful for the case if you desire to add a master > pane that has fixed width (it's fixed even if there is just one window > opened). Especially nice feature if you don't want to have too wide > terminal in a master pane. > > The layout is implemented as an addition to Master layout, so it reuses > most of the code. > ] > [filepath dependency for P.Pass was left out > Adam Vogt **20141221214129 > Ignore-this: 98e63d7b17ac6ebabd8a6b081f5194a1 > ] > [remove unused imports > Adam Vogt **20140815051234 > Ignore-this: b2e5be31b70e6d31827e76bd8c00d200 > ] > [fix build with ghc-6.12 > Adam Vogt **20140815051214 > Ignore-this: d4c4da527db6c8affc151dc210631b85 > ] > [use FiniteBitSize with ghc >= 7.8 > Adam Vogt **20140815051136 > Ignore-this: 90f855fd72406fb3d2640a133d499188 > ] > [Layout.Spacing: Outer window edges now get as much spacing as inner ones > Felix Crux **20141219223646 > Ignore-this: 61363e97939fe857876c8252ac5f0302 > > Layout.Spacing applies a customizable amount of space around the outside > of each > window. At window edges where two windows meet, the total distance > between them > is therefore twice the customized value (one space value from each > window). At > the edge of the screen, however, the spacing is only applied once. This > results > in uneven amounts of spacing and differently-sized gaps on the screen. > > This patch extends the Spacing layout to include a further gap all around > the > edge of the screen, thus making all spaces around windows equal in size. > > ] > [add filepath package dependency needed by Prompt.Pass > Adam Vogt **20140909145216 > Ignore-this: 588ec76e7fccb4219361da7024c98db4 > > filepath comes with ghc, and it's used by xmonad-core anyways > ] > [X.C.Prime: doc tweaks > Devin Mullins **20141002075939 > Ignore-this: 20d6b829b810f48b5e4b4c161b39b312 > ] > [X.A.Navigation2D: add convenience functions for setting config & > keybindings > Devin Mullins **20141002075757 > Ignore-this: ed01137f03a531f73315ed503d1eb6ef > 1. Added 'additionalNav2DKeys' which adds keybindings for the cartesian > product > of direction keys and (modifier, action) pairs given. > 2. Added 'navigation2D' which combines that with 'withNavigation2DConfig'. > 3. Added 'additionalNav2DKeysP' and 'navigation2DP' which do the same, > but use > the 'additionalKeysP' syntax. > ] > [X.C.Prime: doc fixes > Devin Mullins **20141001075855 > Ignore-this: dbbe00791b04df61dcd595c50333fba > ] > [X.C.Prime: add 'withScreens' and friends > Devin Mullins **20141001075250 > Ignore-this: eba37b1ff3da265a4dcc509f538fce4d > The screen equivalent of 'withWorkspaces' lets you more easily define > keys that > move/swap between screens. > > Also, rename wsKeyspecs to wsKeys, and make a couple of doc tweaks. > ] > [Implement proper handling of dynamically changing hostname > Anton Vorontsov **20140901072158 > Ignore-this: 2aeac6d2161e666d40cda6a09f78b208 > > The module implements a proper way of finding out whether the window is > remote or local. > > Just checking for a hostname and WM_CLIENT_MACHINE being equal is often > not enough because the hostname is a changing subject (without any > established notification mechanisms), and thus WM_CLIENT_MACHINE and the > hostname can diverge even for a local window. > > This module solves the problem. As soon as there is a new window created, > we check the hostname and WM_CLIENT_MACHINE, and then we cache the result > into the XMONAD_REMOTE property. > > Notice that XMonad itself does not know anything about hostnames, nor does > it have any dependency on Network.* modules. For this module it is not a > problem: you can provide a mean to get the hostname through your config > file (see usage). Or, if you don't like the hassle of handling dynamic > hostnames (suppose your hostname never changes), it is also fine: this > module will fallback to using environment variables. > ] > [Add Stoppable layout for power saving > Anton Vorontsov **20140901072141 > Ignore-this: a52805d9f3095cd7af48507847ed2fe3 > > This module implements a special kind of layout modifier, which when > applied to a layout, causes xmonad to stop all non-visible processes. In a > way, this is a sledge-hammer for applications that drain power. For > example, given a web browser on a stoppable workspace, once the workspace > is hidden the web browser will be stopped. > > Note that the stopped application won't be able to communicate with X11 > clipboard. For this, the module actually stops applications after a > certain delay, giving a chance for a user to complete copy-paste sequence. > By default, the delay equals to 15 seconds, it is configurable via > 'Stoppable' constructor. > > The stoppable modifier prepends a mark (by default equals to "Stoppable") > to the layout description (alternatively, you can choose your own mark and > use it with 'Stoppable' constructor). The stoppable layout (identified by > a mark) spans to multiple workspaces, letting you to create groups of > stoppable workspaces that only stop processes when none of the workspaces > are visible, and conversely, unfreezing all processes even if one of the > stoppable workspaces are visible. > > To stop the process we use signals, which works for most cases. For > processes that tinker with signal handling (debuggers), another > (Linux-centric) approach may be used. See > https://www.kernel.org/doc/Documentation/cgroups/freezer-subsystem.txt > ] > [X.C.Prime: doc changes > Devin Mullins **20140925203037 > Ignore-this: 51204c1a9f2e6ed21228d2910417fd21 > ] > [X.C.Prime: add withWorkspaces et al. > Devin Mullins **20140925203034 > Ignore-this: 65f691270110cc5de13c950d9dcb0c17 > This allows easier configuration of workspaces and their keybindings. > Required > generalizing the 'Prime' type, so lots of other lines changed in rather > trivial > ways. > ] > [X.C.Prime: add ifThenElse binding > Devin Mullins **20140924191509 > Ignore-this: ae775c418c27301b9c12d2a233502cec > This is necessary for if-then-else support in the user's config. > ] > [X.C.Prime: doc fixes > Devin Mullins **20140915080601 > Ignore-this: 15e3c445a99d3b2d3a235aa76119797 > ] > [X.C.Prime: fix 'def' hyperlink in doc > Devin Mullins **20140914075352 > Ignore-this: a1de1d81a5f140ab7d90edbf393e9bda > ] > [XMonad.Config.Prime, a do-notation for config > Devin Mullins **20140914064828 > Ignore-this: f7397aa6e6efe5d76acebfa22c567baa > Note that the use of RebindableSyntax is because of the need to vary the > layoutHook type throughout the config. The alternative, using the > existential > Layout type, was rejected because it required TemplateHaskell in order to > look > nice, and TemplateHaskell is not portable. > > I've tried to make a version of (>>) that also worked on normal monads, > but > have had no luck as of yet. Maybe some intrepid soul can add it later. > ] > [X.P.Shell: fix doc typo > me at twifkak.com**20130317115516 > Ignore-this: bdd385a9142ed039a917d135e76293fe > ] > [reverse workspaces, so that switching to a dynamic workspace group > restores the focus to the screen that was focused at group creation time > nwfilardo at gmail.com**20140913174118 > Ignore-this: b74c02b1892159694827e35122c2d517 > ] > [add filepath dependency, needed by new X.P.Pass module > me at twifkak.com**20140913070926 > Ignore-this: fec97086c1e66cf8a036265bd1a970a8 > ] > [add-new-xmonad-prompt-pass > eniotna.t at gmail.com**20140829131928 > Ignore-this: 11e85dfe3d24cef88d8d89f4e7b1ec0b > This module provides 3 to ease passwords manipulation > (generate, read, remove): > > - one to lookup passwords in the password-storage. > > - one to generate a password for a given password label that the user > inputs. > > - one to delete a stored password for a given password label that the > user inputs. > > All those prompts benefit from the completion system provided by the > module . > > The password store is setuped through an environment variable > PASSWORD_STORE_DIR. > If this is set, use the content of the variable. > Otherwise, the password store is located on user's home > @$HOME\/.password-store at . > > > Source: > > - The password storage implementation is < > http://git.zx2c4.com/password-store the password-store cli>. > > - Inspired from > ] > [use Data.Map instead of Data.Map.Strict to support containers < 0.5 > Adam Vogt **20140815043141 > Ignore-this: 436d18657d8499f4ce57311e84503d9f > ] > [config-mate > allbery.b at gmail.com**20140803020659 > Ignore-this: d5de258c0a28cd5ba64a59cf37cd480a > Initial support for the Mate desktop environment (http://mate-desktop.org > ). > Based on existing Gnome 2 support, since Mate is a maintained fork of > Gnome 2. > ] > [debug-managehook > allbery.b at gmail.com**20140803020601 > Ignore-this: 51f9255b496cca79e4a53e274c400ecc > A set of hooks, and convenience combinators, to help with ManageHook > debugging. > Ordinary users may well want to use debugManageHookOn in normal configs, > specifying a key sequence which can be pressed before running a command in > order to capture debug information just for that command's main window. > > This is especially useful when trying to diagnose issues such as programs > that do not play well with SpawnOn, or ManageHook matching on 'title' when > the program does not set the window title until after it is mapped. > ] > [debug-debug > allbery.b at gmail.com**20140803020530 > Ignore-this: cbb2b1d99293e3a4d02a256c2733aeb0 > Various fixes and enhancements to DebugWindow and DebugStack. ManageDebug > requires these fixes, but some of them are significant even if not using > ManageDebug. > ] > [derive Applicative instances to suppress AMP warning > Adam Vogt **20140710163950 > Ignore-this: c2110d07bccc61462c3fbf73c900aaa1 > ] > [clean up cabal file and drop support for base < 3 > Adam Vogt **20140710013255 > Ignore-this: 76b142e2b114604feac9b8e41cf71ab > ] > [add-duck-duck-go-search-engine > eniotna.t at gmail.com**20140617174246 > Ignore-this: 29bbfb2d07d9ddf36bf0268a4e255f81 > ] > [XSelection: getSelection: fix connection exhaustion bug (issue #573); > include warning > gwern at gwern.net**20140601025019 > Ignore-this: add21190fc07338b243c2241cc746119 > ] > [Fix dbus-send call in XMonad.Config.Gnome > md143rbh7f at gmail.com**20140129032114 > Ignore-this: ed62458b55c8b34b77f73027eeee1a73 > dbus-send --print-reply=string is invalid, but it was silently ignored > until recently: > > http://cgit.freedesktop.org/dbus/dbus/commit/tools/dbus-send.c?id=c690ee4351f99ed5e629ffcf5f4a2edcd418d103 > I've changed XMonad.Config.Gnome to run --print-reply=literal, since > that's what the old behavior was. > ] > [warning police (unused variables) > Adam Vogt **20140505001242 > Ignore-this: a15b4d844b1da4f1f1f9b6095c968705 > ] > [This patch makes the Ssh extension works with **user** arguments in ssh, > .e.g ssh admin at localhost. > linxray at gmail.com**20140504091120 > Ignore-this: 297673e11d3049c4f127aac3e172d361 > ] > [remove trailing whitespace in L.BinarySpacePartition > Adam Vogt **20140501011943 > Ignore-this: 8dd677978992e0854801b8f254463dc2 > ] > [replace Bound with the equivalent Direction2D > Adam Vogt **20140501011540 > Ignore-this: b1f1c256aba07f70918fe1d693c8087b > ] > [remove unused extension in BSP > Adam Vogt **20140501011455 > Ignore-this: a4962486b2aa3980536bff19a537451e > ] > [Add BinarySpacePartition layout > benweitzman at gmail.com**20140430205848 > Ignore-this: a85d1dc51bf54c59ae2bd9d948cc1088 > ] > [X.Actions.DynamicWorkspaceGroups: export new function addRawWSGroup > Brent Yorgey **20140428142901 > Ignore-this: a487882c9571bf91ff921d6561bb4cc6 > ] > [Remove unneeded context with the IfMax layout instance > Adam Vogt **20140422221105 > Ignore-this: 3b8ac316f56df6a84420754db769fb0 > > Extra constraints on instances are about as useful as -XDataTypeContexts > ] > [Adding side tabs and replacing TabbarLocation with Direction2D. > nrujac at gmail.com**20140219200811 > Ignore-this: edabeec973b4e0d61515818367689843 > ] > [warning police > Daniel Wagner **20140316183747 > Ignore-this: fd16435ccdd3fee8924723cc690cc239 > ] > [New module: XMonad.Util.WindowState > Dmitry Bogatov **20140218100229 > Ignore-this: 14a6fa263c423cd8cca3b2645b3930d7 > > Save almost arbitary data per window > ] > [Add side tabs to the tabbed layout. > nrujac at gmail.com**20140213215247 > Ignore-this: f81bafe9cb75a30ed6bbbe68cf5d66c0 > ] > [SpawnNamedPipe hlint cleanup > cwills.dev at gmail.com**20140202213613 > Ignore-this: dbb68c4c5522026bd108d0158e747b48 > ] > [document and cleanup SpawnNamedPipe > cwills.dev at gmail.com**20140202211000 > Ignore-this: b264278f1f1ab1f18b37245a5ff33136 > ] > [Added SpawnNamedPipe > cwills.dev at gmail.com**20140202143415 > Ignore-this: 87797ffffc8d0fd088482bd0c5baf0e > ] > [Make commandToComplete in XMonad.Prompt.Shell complete last word > md143rbh7f at gmail.com**20140130200050 > Ignore-this: b0fe22fdd7b9409835fd0ca069f2e01a > > The following change from 2013-02-09 breaks shell completion for me: > hunk ./XMonad/Prompt/Shell.hs 65 > + commandToComplete _ c = c > > It seems to be passing the entire string into compgen in order to get the > file completions, but it should only pass the last word. I propose > reverting this change. Comments are appreciated. > ] > [expose and document X.L.IndependentScreens.marshallSort > Daniel Wagner **20140128212844 > Ignore-this: 90c1437c6ffe1dbd8f4a4ed192097ec > ] > [ServerMode properly indent > Adam Vogt **20131219201440 > Ignore-this: 761b39c3e3c90b6123f068e8b1d34e5d > ] > [remove ServerMode tabs > Adam Vogt **20131219201000 > Ignore-this: f21448c248ec0ac289c309ed964ebcff > ] > [fix -Wall ServerMode > Adam Vogt **20131219181030 > Ignore-this: 708dd5fc60f43dee3d1da085002052f > ] > [documentation note that ServerMode is similar to wmctrl > Adam Vogt **20131219180748 > Ignore-this: 3215bdf1c698c798eca8ed7f62a0f591 > ] > [Generalized XMonad.Hooks.ServerMode > polson2 at hawk.iit.edu**20131216025100 > Ignore-this: e58da3b168a1058f32982833ea25a739 > ] > [IfMax-Layout > Ilya Portnov **20131201072634 > Ignore-this: dac53f2a0505e740f05fdf03f1db0c21 > This adds a new ("conditional") layout, IfMax, which simply runs one > layout, if there are <= N windows, and else runs another layout. > ] > [fix UrgencyHook and add filterUrgencyHook > Adam Vogt **20130924224738 > Ignore-this: 3b7c62275701e6758397977c5c09b744 > ] > [export XMonad.Hooks.UrgencyHook.clearUrgency (issue 533) > Adam Vogt **20130923031349 > Ignore-this: dafe5763d9abcfa606f5c1a8cf5c57d6 > ] > [minor documentation fix: manageDocks doesn't do anything with struts, so > don't claim it does > Daniel Wagner **20130814125106 > Ignore-this: a2610d6c1318ac0977abfc21d1b91632 > ] > [don't pretend to be LG3D in X.C.Dmwit because this confuses modern GTK > Daniel Wagner **20130813211636 > Ignore-this: 8f728dc1b4bf5e472d99419cc5920e51 > ] > [XMonad.Actions.UpdatePointer: generalise updatePointer > Liyang HU **20130730071007 > Ignore-this: 3374a62b6c63dcc152dbf843cd0577f0 > > ] > [XMonad.Actions.UpdatePointer: document TowardsCentre > Liyang HU **20130730053746 > Ignore-this: 2d684b12e4fff0ebec254bea4a4546a3 > > ] > [Haddock formatting in H.Minimize > Adam Vogt **20130723155658 > Ignore-this: 5db3186a51dec58f78954466ded339cb > ] > [Bump version (and xmonad dependency) to 0.12 > Adam Vogt **20130720205857 > Ignore-this: ce165178ca916223501f266339f1de39 > > This makes a breakage due to missing patches in core a bit more obvious. > Previously you would have a build failure regarding some missing > identifiers > (def re-exported by XMonad from Data.Default), while after applying this > patch > it will be clear that xmonad-core needs to be updated. > ] > [Fix issue 551 by also getting manpath without -g flag. > Adam Vogt **20130716030536 > Ignore-this: ded2d51eb7b7697c0fdfaa8158d612df > > Instead of taking Ondrej's approach of figuring out which man (man-db or > http://primates.ximian.com/~flucifredi/man/) is used by the system, just > try > both sets of flags. > ] > [Escape dzen markup and remove xmobar tags from window titles by default. > Adam Vogt **20130708144813 > Ignore-this: cf56bff752fbf78ea06d5c0cb755f615 > > The issue was that window titles, such as those set by, for example a > browser, > could set the window title to display something like > > normal title > > Which could be executed by xmobar (or dzen). > > This adds a ppTitleSanitize which does the above functions. This way when > users > override ppTitle, the benefits are not lost. > > Thanks to Ra?l Benencia and Joachim Breitner for bringing this to my > attention. > ] > [DynamicBars-use-ExtensibleState > gopsychonauts at gmail.com**20130618074755 > Ignore-this: afacba51af2be8ede65b9bcf9b002a7 > > Hooks.DynamicBars was previously using an MVar and the unsafePerformIO > hack ( > http://www.haskell.org/haskellwiki/Top_level_mutable_state ) to store bar > state. Since ExtensibleState exists to solve these sorts of problems, I've > switched the file over to use unsafePerformIO instead. > > Some functions' types had to be changed to allow access to XState, but the > public API is unchanged. > > ] > [Catch exceptions when finding commands on PATH in Prompt.Shell > Thomas Tuegel **20130616230219 > Ignore-this: 5a4d08c80301864bc14ed784f1054c3f > ] > [Fix haddock parse error in X.A.LinkWorkspaces > Adam Vogt **20130528133448 > Ignore-this: 42f05cf8ca9e6d1ffae3bd20666d87ab > ] > [use Data.Default wherever possible, and deprecate the things it replaces > Daniel Wagner **20130528013909 > Ignore-this: 898458b1d2868a70dfb09faf473dc7aa > ] > [eliminate references to defaultConfig > Daniel Wagner **20130528005825 > Ignore-this: 37ae613e4b943e99c5200915b9d95e58 > ] > [minimal change needed to get xmonad-contrib to build with xmonad's > data-default patch > Daniel Wagner **20130528001040 > Ignore-this: 291e4f6cd74fc2b808062e0369665170 > ] > [Remove unneeded XSync call in Layout.ShowWName > Francesco Ariis **20130517153341 > Ignore-this: 4d107c680572eff464c8f6ed9fabdd41 > ] > [Remove misleading comment: we definitely don't support ghc-6.6 anymore > Adam Vogt **20130514215851 > Ignore-this: 2d071cb05709a16763d039222264b426 > ] > [Fix module name in comment of X.L.Fullscreen > Adam Vogt **20130514215727 > Ignore-this: cb5cf18c301c5daf5e1a2527da1ef6bf > ] > [Minor update to cabal file (adding modules & maintainership) > Adam Vogt **20130514215632 > Ignore-this: 82785e02e544e1f797799bed5b5d9be2 > ] > [Remove trailing whitespace in X.A.LinkWorkspaces > Adam Vogt **20130514215421 > Ignore-this: 5015ab4468e7931876eb66b019af804c > ] > [Update documentation of LinkWorkspaces Module > quesel at informatik.uni-oldenburg.de**20110328072813 > Ignore-this: da863534931181f551c9c54bc4076c05 > ] > [Added a module for linking workspaces > quesel at informatik.uni-oldenburg.de**20110210165018 > Ignore-this: 1dba2164cc3387409873d33099596d91 > > This module provides a way to link certain workspaces in a multihead > setup. > That way, when switching to the first one the other heads display the > linked > workspaces. > ] > [Cache results from calcGap in ManageDocks > Adam Vogt **20130425155811 > Ignore-this: e5076fdbdfc68bc159424dd4e0f14456 > > http://www.haskell.org/pipermail/xmonad/2013-April/013670.html > ] > [Remove unnecessary contexts from L.MultiToggle > Adam Vogt **20130217163356 > Ignore-this: 6b0e413d8c3a58f62088c32a96c57c51 > ] > [Generalises modWorkspace to take any layout-transforming function > gopsychonauts at gmail.com**20130501151425 > Ignore-this: 28c7dc1f6216bb1ebdffef5434ccbcbd > > modWorkspace already was capable of modifying the layout with an arbitrary > layout -> layout function, but its original type restricted it such that > it > could only apply a single LayoutModifier; this was often inconvenient, as > for > example it was not possible simply to compose LayoutModifiers for use with > modWorkspace. > > This patch also reimplements onWorkspaces in terms of modWorkspaces, > since with > the latter's less restrictive type this is now possible. > ] > [since XMonad.Config.Dmwit mentions xmobar, we should include the > associated .xmobarrc file > Daniel Wagner **20130503194055 > Ignore-this: 2f6d7536df81eb767262b79b60eb1b86 > ] > [warning police > Daniel Wagner **20130502012700 > Ignore-this: ae7412ac77c57492a7ad6c5f8f50b9eb > ] > [XMonad.Config.Dmwit > Daniel Wagner **20130502012132 > Ignore-this: 7402161579fd2e191b60a057d955e5ea > ] > [minor fixes to the haddock markup in X.L.IndependentScreens > Daniel Wagner **20130411193849 > Ignore-this: b6a139aa43fdb39fc1b86566c0c34c7a > ] > [add whenCurrentOn to X.L.IndependentScreens > Daniel Wagner **20130408225251 > Ignore-this: ceea3d391f270abc9ed8e52ce19fb1ac > ] > [Allow to specify the initial gaps' states in X.L.Gaps > Paul Fertser **20130222072232 > Ignore-this: 31596d918d0050e36ce3f64f56205a64 > ] > [should bump X11 dependency, too, to make sure we have getAtomName > Daniel Wagner **20130225180527 > Ignore-this: 260711f27551f18cc66afeb7b4846b9f > ] > [getAtomName is now defined in the X11 library > Daniel Wagner **20130225180323 > Ignore-this: 3b9e17c234679e98752a47c37132ee4e > ] > [Allow to limit maximum row count in X.Prompt completion window > Paul Fertser **20130221122050 > Ignore-this: 923656f02996f2de2b1336275392c5f9 > > On a keyboard-less device (such as a smartphone), where one has to use > an on-screen keyboard, the maximum completion window height must be > limited to avoid overlapping the keyboard. > ] > [Note in U.NameActions that xmonad core can list default keys now > Adam Vogt **20130217233026 > Ignore-this: 937bff636fa88171932d5192fe8e290b > ] > [Export U.NamedActions.addDescrKeys per evaryont's request. > Adam Vogt **20130217232619 > Ignore-this: a694a0a3ece70b52fba6e8f688d86344 > ] > [Add EWMH DEMANDS_ATTENTION support to UrgencyHook. > Maarten de Vries **20130212181229 > Ignore-this: 5a4b314d137676758fad9ec8f85ce422 > > Add support for the _NET_WM_STATE_DEMANDS_ATTENTION atom > by treating it the same way as the WM_HINTS urgency flag. > > ] > [Unconditionally set _NET_WORKAREA in ManageDocks > Adam Vogt **20130117180851 > Ignore-this: 9f57e53fba9573d8a92cf153beb7fe7a > ] > [spawn command when no completion is available (if alwaysHighlight is > True); changes commandToComplete in Prompt/Shell to complete the whole word > instead of using getLastWord > c.lopez at kmels.net**20130209190456 > Ignore-this: ca7d354bb301b555b64d5e76e31d10e8 > ] > [order-unindexed-ws-last > matthewhague at zoho.com**20120703222726 > Ignore-this: 4af8162ee8b16a60e8fd62fbc915d3c0 > > Changes the WorkspaceCompare module's comparison by index to put > workspaces without an index last (rather than first). > ] > [SpawnOn modification for issue 523 > Adam Vogt **20130114014642 > Ignore-this: 703f7dc0f800366b752f0ec1cecb52e5 > > This moves the function to help clean up the `Spawner' to the ManageHook > rather than in functions like spawnOn. Probably it makes no difference, > the > reason is because there's one manageSpawn function but many different so > this > way there are less functions to write. > ] > [Update L.TrackFloating.useTransient example code > Adam Vogt **20130112041239 > Ignore-this: e4e31cf1db742778c1d59d52fdbeed7a > > Suggest useTransient goes to the right of trackFloating which is the > configuration actually tested. > ] > [Adapt ideas of issue 306 patch to a new modifier in L.TrackFloating > Adam Vogt **20130112035701 > Ignore-this: d54d27b71b97144ef0660f910fd464aa > ] > [Make X.A.CycleWS not rely on hidden WS order > Dmitri Iouchtchenko **20130109023328 > Ignore-this: 8717a154b33253c5df4e9a0ada4c2c3e > ] > [Add X.H.WorkspaceHistory > Dmitri Iouchtchenko **20130109023307 > Ignore-this: c9e7ce33a944facc27481dde52c7cc80 > ] > [Allow removing arbitrary workspaces > Dmitri Iouchtchenko **20121231214343 > Ignore-this: 6fce4bd3d0c5337e5122158583138e74 > ] > [Remove first-hidden restriction from > X.A.DynamicWorkspaces.removeWorkspace' > Dmitri Iouchtchenko **20121231214148 > Ignore-this: 55fb0859e9a5f476a834ecbdb774aac8 > ] > [Add authorspellings file for `darcs show authors'. > Adam Vogt **20130101040031 > Ignore-this: c3198072ebc6a71d635bec4d8e2c78fd > > This authorspellings file includes a couple people who've contributed to > xmonad > (not XMonadContrib). When people have multiple addresses, the most recent > one > has been picked. > ] > [TAG 0.11 > Adam Vogt **20130101014231 > Ignore-this: 57cf32412fd1ce912811cb7fafe930f5 > ] > Patch bundle hash: > 618fd3dbf4425e0a0871a8474b9b17f83c9e2ac2 > > > -- > brandon s allbery kf8nh sine nomine > associates > allbery.b at gmail.com > ballbery at sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > _______________________________________________ > xmonad mailing list > xmonad at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad > -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Thu Apr 23 15:47:24 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Thu, 23 Apr 2015 11:47:24 -0400 Subject: [xmonad] Patch: Re-order XMonad.Hooks.EwmhDesktops hook insertion In-Reply-To: References: Message-ID: On Thu, Apr 23, 2015 at 10:55 AM, Brent Yorgey wrote: > This looks sensible. Can you resend it as an actual attachment? I'll be > happy to apply it. I had to redo it, since I didn't save the original and reverted it in my local copy afterward (since the last time I'd sent a patch, it was edited upstream and didn't match my repo any more). -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ewmh_hook_order.dpatch Type: application/octet-stream Size: 35231 bytes Desc: not available URL: From codesite-noreply at google.com Fri Apr 24 18:53:13 2015 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Fri, 24 Apr 2015 18:53:13 +0000 Subject: [xmonad] Issue 597 in xmonad: xmonad-contrib-0.11.4 does not compile In-Reply-To: <3-3425899027203913298-5220352385308706020-codesite-noreply=google.com@googlecode.com> References: <3-3425899027203913298-5220352385308706020-codesite-noreply=google.com@googlecode.com> <0-3425899027203913298-5220352385308706020-codesite-noreply=google.com@googlecode.com> Message-ID: <4-3425899027203913298-5220352385308706020-codesite-noreply=google.com@googlecode.com> Comment #4 on issue 597 by alexandr... at gmail.com: xmonad-contrib-0.11.4 does not compile https://code.google.com/p/xmonad/issues/detail?id=597 This issue is marked as "Fixed", does it mean that `cabal install xmonad-contrib` should not fail anymore? Or does it try to install some "stable" version of the package? If so, how can I install the patched bleeding-edge version? Sorry for such an uneducated question, but Haskell development/package management are quite a mystery for an outsider :) -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings From codesite-noreply at google.com Sun Apr 26 20:05:51 2015 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Sun, 26 Apr 2015 20:05:51 +0000 Subject: [xmonad] Issue 597 in xmonad: xmonad-contrib-0.11.4 does not compile In-Reply-To: <4-3425899027203913298-5220352385308706020-codesite-noreply=google.com@googlecode.com> References: <4-3425899027203913298-5220352385308706020-codesite-noreply=google.com@googlecode.com> <0-3425899027203913298-5220352385308706020-codesite-noreply=google.com@googlecode.com> Message-ID: <5-3425899027203913298-5220352385308706020-codesite-noreply=google.com@googlecode.com> Comment #5 on issue 597 by daniel.w... at gmail.com: xmonad-contrib-0.11.4 does not compile https://code.google.com/p/xmonad/issues/detail?id=597 "Fixed" means that things will work without extra effort at the time of next release. To get the bleeding-edge version, follow the instructions for installing from darcs on the official instructions at http://xmonad.org/download.html; that is: darcs get http://code.haskell.org/xmonad darcs get http://code.haskell.org/XMonadContrib cabal install ./xmonad ./XMonadContrib -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings From codesite-noreply at google.com Thu Apr 30 04:48:52 2015 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Thu, 30 Apr 2015 04:48:52 +0000 Subject: [xmonad] Issue 602 in xmonad: xmonad hangs when clickJustFocuses = False and the user clicks outside of the focused window while a submap is active. In-Reply-To: <2-3425899027203913298-11954270657760967272-codesite-noreply=google.com@googlecode.com> References: <2-3425899027203913298-11954270657760967272-codesite-noreply=google.com@googlecode.com> <0-3425899027203913298-11954270657760967272-codesite-noreply=google.com@googlecode.com> Message-ID: <3-3425899027203913298-11954270657760967272-codesite-noreply=google.com@googlecode.com> Comment #3 on issue 602 by untfu... at gmail.com: xmonad hangs when clickJustFocuses = False and the user clicks outside of the focused window while a submap is active. https://code.google.com/p/xmonad/issues/detail?id=602 Thank you for your response. Following your suggestion, I've been working on a prototype that may eventually lead to a handleEventHook submap. However, so far I've observed three behaviors that may be problematic: 1. handleEventHook does not process KeyEvents for any particular key (e.g. if I wanted to put xK_f into my submap) unless I put a dummy binding for that key in my config's "keys = ..." 2. If I do put a dummy binding in, xmonad grabs the KeyEvent for that key under all circumstances - I can't turn it on or off - and never "resends" them back to the window in question. So if I bind xK_f for example, programs no longer receive an "f" unless I resend it myself using (the only working one I've found so far) XMonad.Util.Paste.sendKey. 3. Though sendKey generally seems to work, some programs react differently to the "fake" sendKey events. Thankfully, it's been limited to some subtle cursor behaviors in emacs so far. Is there any method that does not require using sendKey - say, a way to turn certain keybindings on/off, or otherwise to make it so that xmonad "forwards" KeyEvents when they are no longer being captured by a submap? Alternatively, is there some other approach I should be using? Thanks again. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings From codesite-noreply at google.com Thu Apr 30 05:07:15 2015 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Thu, 30 Apr 2015 05:07:15 +0000 Subject: [xmonad] Issue 602 in xmonad: xmonad hangs when clickJustFocuses = False and the user clicks outside of the focused window while a submap is active. In-Reply-To: <3-3425899027203913298-11954270657760967272-codesite-noreply=google.com@googlecode.com> References: <3-3425899027203913298-11954270657760967272-codesite-noreply=google.com@googlecode.com> <0-3425899027203913298-11954270657760967272-codesite-noreply=google.com@googlecode.com> Message-ID: <4-3425899027203913298-11954270657760967272-codesite-noreply=google.com@googlecode.com> Comment #4 on issue 602 by untfu... at gmail.com: xmonad hangs when clickJustFocuses = False and the user clicks outside of the focused window while a submap is active. https://code.google.com/p/xmonad/issues/detail?id=602 Thank you for your response. Following your suggestion, I've been working on a prototype that may eventually lead to a handleEventHook submap. However, so far I've observed three behaviors that may be problematic: 1. handleEventHook does not process KeyEvents for any particular key (e.g. if I wanted to put xK_f into my submap) unless I put a dummy binding for that key in my config's "keys = ..." 2. If I do put a dummy binding in, xmonad grabs the KeyEvent for that key under all circumstances - I can't turn it on or off - and never "resends" them back to the window in question. So if I bind xK_f for example, programs no longer receive an "f" unless I resend it myself using (the only working one I've found so far) XMonad.Util.Paste.sendKey. 3. Some programs react differently to the "fake" sendKey events. So far, certain file managers (thunar, nemo) doesn't recognize the keys, and some save dialogs won't let you create folders using those keys. Is there any method that does not require using sendKey - say, a way to turn certain keybindings on/off, or otherwise to make it so that xmonad "forwards" KeyEvents when they are no longer being captured by a submap? Alternatively, is there some other approach I should be using? Thanks again. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings From gauthier at ostervall.se Thu Apr 30 14:20:24 2015 From: gauthier at ostervall.se (=?UTF-8?Q?Gauthier_=C3=96stervall?=) Date: Thu, 30 Apr 2015 16:20:24 +0200 Subject: [xmonad] xmobar crash analysis Message-ID: Hi all! I hope it's ok to ask xmobar questions here, it fills related enough. Frankly, I don't know if my problem is caused by xmobar or xmonad. Every now and then, maybe every other day, my xmobar crashes. It just disappears, leaving a gap where I can see my background picture. The only way to make it reappear is to log out and in. Restarting xmobar from a terminal (same command as in my xmonad.hs) starts the process, says that "Fields missing from config defaulted: overrideRedirect,persistent", but the bar does not appear. Mod+q doesn't help. What I wonder is how I find crash and debug info about this. /var/log/syslog doesn't mention anything about xmobar, xmonad.errors is empty. What is going on? Thanks, Gauthier From allbery.b at gmail.com Thu Apr 30 14:35:56 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Thu, 30 Apr 2015 14:35:56 +0000 Subject: [xmonad] xmobar crash analysis In-Reply-To: References: Message-ID: On Thu, Apr 30, 2015 at 2:20 PM, Gauthier ?stervall wrote: > What I wonder is how I find crash and debug info about this. > /var/log/syslog doesn't mention anything about xmobar, xmonad.errors > is empty. What is going on? > It's going to be in the session log, wherever that is: for `startx` it defaults to the virtual console you ran it on (you can put a redirection such as `exec >~/.xsession-errors 2>&1` near the top of ~/.xinitrc to change it); for display managers it's usually ~/.xsession-errors. Some systemd-based systems may instead use a systemd log accessed via journalctl. xmonad.errors is *only* used when compiling an xmonad config, not for any other purpose. Because of the specific way this file is used to collect output from compiling an xmonad config, you should not try to use it for anything else. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From codesite-noreply at google.com Thu Apr 30 15:41:10 2015 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Thu, 30 Apr 2015 15:41:10 +0000 Subject: [xmonad] Issue 602 in xmonad: xmonad hangs when clickJustFocuses = False and the user clicks outside of the focused window while a submap is active. In-Reply-To: <4-3425899027203913298-11954270657760967272-codesite-noreply=google.com@googlecode.com> References: <4-3425899027203913298-11954270657760967272-codesite-noreply=google.com@googlecode.com> <0-3425899027203913298-11954270657760967272-codesite-noreply=google.com@googlecode.com> Message-ID: <5-3425899027203913298-11954270657760967272-codesite-noreply=google.com@googlecode.com> Comment #5 on issue 602 by mwlochb... at gmail.com: xmonad hangs when clickJustFocuses = False and the user clicks outside of the focused window while a submap is active. https://code.google.com/p/xmonad/issues/detail?id=602 To fix problem 1 (without invoking problem 2), you want to add keyPressMask to your config's clientMask. This option is available in the darcs source but it doesn't seem to have made it to any hackage releases yet. I have noticed problem 3 but can't offer any way to solve it. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings From codesite-noreply at google.com Thu Apr 30 16:02:00 2015 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Thu, 30 Apr 2015 16:02:00 +0000 Subject: [xmonad] Issue 602 in xmonad: xmonad hangs when clickJustFocuses = False and the user clicks outside of the focused window while a submap is active. In-Reply-To: <5-3425899027203913298-11954270657760967272-codesite-noreply=google.com@googlecode.com> References: <5-3425899027203913298-11954270657760967272-codesite-noreply=google.com@googlecode.com> <0-3425899027203913298-11954270657760967272-codesite-noreply=google.com@googlecode.com> Message-ID: <6-3425899027203913298-11954270657760967272-codesite-noreply=google.com@googlecode.com> Comment #6 on issue 602 by allber... at gmail.com: xmonad hangs when clickJustFocuses = False and the user clicks outside of the focused window while a submap is active. https://code.google.com/p/xmonad/issues/detail?id=602 You should probably look closer at the approach in comment 2 (https://code.google.com/p/xmonad/issues/detail?id=602#c2) instead. Arguably a key sequence should not involve mouse events at all and should simply give up if it sees one. Use peekEvent, which leaves the event in the input queue so that it doesn't need to be reinjected as a synthetic event that programs may ignore for security reasons. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings From codesite-noreply at google.com Thu Apr 30 16:37:10 2015 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Thu, 30 Apr 2015 16:37:10 +0000 Subject: [xmonad] Issue 603 in xmonad: Problems with toggling focus on Chrome Message-ID: <0-3425899027203913298-3827064008373761146-codesite-noreply=google.com@googlecode.com> Status: New Owner: ---- New issue 603 by p... at cnphil.com: Problems with toggling focus on Chrome https://code.google.com/p/xmonad/issues/detail?id=603 What steps will reproduce the problem? 1. In tiling mode, open up Chrome 2. Open up another window, say urxvt 3. Try toggling back and forth the focus with What is the expected output? What do you see instead? Chrome should be responding to keyboard, mouse movement. But it just does not seem to realize it is on focus. What version of the product are you using? On what operating system? xmonad 0.11.1 ghc 7.10.1 Chrome 43 beta Arch Linux Are you using an xmonad.hs? Please attach it and the output of "xmonad --recompile". The problem persists even without an xmonad.hs Please provide any additional information below. In the attached image, you can see that the currently focused window is red-bordered (lower right), but it's not responding to keyboard strokes or anything unless I explicitly move the cursor there and click on it. Attachments: 2015-05-01-003015_2560x1600_scrot.png 468 KB -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings From codesite-noreply at google.com Thu Apr 30 16:49:08 2015 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Thu, 30 Apr 2015 16:49:08 +0000 Subject: [xmonad] Issue 603 in xmonad: Problems with toggling focus on Chrome In-Reply-To: <0-3425899027203913298-3827064008373761146-codesite-noreply=google.com@googlecode.com> References: <0-3425899027203913298-3827064008373761146-codesite-noreply=google.com@googlecode.com> Message-ID: <1-3425899027203913298-3827064008373761146-codesite-noreply=google.com@googlecode.com> Comment #1 on issue 603 by allber... at gmail.com: Problems with toggling focus on Chrome https://code.google.com/p/xmonad/issues/detail?id=603 Does your xmonad.hs use EwmhDesktops? If not, please try configuring it: http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Hooks-EwmhDesktops.html Increasingly, recent gtk3 does not actually speak X11 but only the Wayland emulation parts of EWMH, which means that it is less and less compatible with non-Gnome3 and plays less and less well with applications that are not based on the same or later version of gtk3. I suspect whatever gtk3 this Chrome is using simply does not recognize X11 focus any more, only Wayland emulation focus. This suggests that Chrome will in the future not be worth the effort on X11 at all, unless you run nothing but Gnome3 environment and approved Gnome3-compatible programs. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings From codesite-noreply at google.com Thu Apr 30 16:50:08 2015 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Thu, 30 Apr 2015 16:50:08 +0000 Subject: [xmonad] Issue 603 in xmonad: Problems with toggling focus on Chrome In-Reply-To: <1-3425899027203913298-3827064008373761146-codesite-noreply=google.com@googlecode.com> References: <1-3425899027203913298-3827064008373761146-codesite-noreply=google.com@googlecode.com> <0-3425899027203913298-3827064008373761146-codesite-noreply=google.com@googlecode.com> Message-ID: <2-3425899027203913298-3827064008373761146-codesite-noreply=google.com@googlecode.com> Comment #2 on issue 603 by p... at cnphil.com: Problems with toggling focus on Chrome https://code.google.com/p/xmonad/issues/detail?id=603 Chrome 42 or older does not have this problem. I've tested Chrome 43 under i3 and Plasma 5, both works. Seems to be xmonad's issue. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings From codesite-noreply at google.com Thu Apr 30 16:52:18 2015 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Thu, 30 Apr 2015 16:52:18 +0000 Subject: [xmonad] Issue 603 in xmonad: Problems with toggling focus on Chrome In-Reply-To: <2-3425899027203913298-3827064008373761146-codesite-noreply=google.com@googlecode.com> References: <2-3425899027203913298-3827064008373761146-codesite-noreply=google.com@googlecode.com> <0-3425899027203913298-3827064008373761146-codesite-noreply=google.com@googlecode.com> Message-ID: <3-3425899027203913298-3827064008373761146-codesite-noreply=google.com@googlecode.com> Comment #3 on issue 603 by allber... at gmail.com: Problems with toggling focus on Chrome https://code.google.com/p/xmonad/issues/detail?id=603 Yes, I imagine both come with Wayland emulation aka EWMH out of the box. You must explicitly configure that in xmonad via EwmhDesktops; only ICCCM support is enabled by default. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings From codesite-noreply at google.com Thu Apr 30 17:00:35 2015 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Thu, 30 Apr 2015 17:00:35 +0000 Subject: [xmonad] Issue 603 in xmonad: Problems with toggling focus on Chrome In-Reply-To: <3-3425899027203913298-3827064008373761146-codesite-noreply=google.com@googlecode.com> References: <3-3425899027203913298-3827064008373761146-codesite-noreply=google.com@googlecode.com> <0-3425899027203913298-3827064008373761146-codesite-noreply=google.com@googlecode.com> Message-ID: <4-3425899027203913298-3827064008373761146-codesite-noreply=google.com@googlecode.com> Comment #4 on issue 603 by p... at cnphil.com: Problems with toggling focus on Chrome https://code.google.com/p/xmonad/issues/detail?id=603 Solved after configuring EWMH. Thank you so much for the quick response! :-) -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings From codesite-noreply at google.com Thu Apr 30 17:11:15 2015 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Thu, 30 Apr 2015 17:11:15 +0000 Subject: [xmonad] Issue 602 in xmonad: xmonad hangs when clickJustFocuses = False and the user clicks outside of the focused window while a submap is active. In-Reply-To: <6-3425899027203913298-11954270657760967272-codesite-noreply=google.com@googlecode.com> References: <6-3425899027203913298-11954270657760967272-codesite-noreply=google.com@googlecode.com> <0-3425899027203913298-11954270657760967272-codesite-noreply=google.com@googlecode.com> Message-ID: <7-3425899027203913298-11954270657760967272-codesite-noreply=google.com@googlecode.com> Comment #7 on issue 602 by mwlochb... at gmail.com: xmonad hangs when clickJustFocuses = False and the user clicks outside of the focused window while a submap is active. https://code.google.com/p/xmonad/issues/detail?id=602 If you return (All True) from your event handler, then the event will be left on the queue (unless I've badly misunderstood something?). peekEvent lets you handle the next event regardless of whether it's one that xmonad cares about, but if you just want to use the submap for keypresses and abort on mouse events then handleEventHook seems cleaner to me. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings From codesite-noreply at google.com Thu Apr 30 17:21:16 2015 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Thu, 30 Apr 2015 17:21:16 +0000 Subject: [xmonad] Issue 602 in xmonad: xmonad hangs when clickJustFocuses = False and the user clicks outside of the focused window while a submap is active. In-Reply-To: <7-3425899027203913298-11954270657760967272-codesite-noreply=google.com@googlecode.com> References: <7-3425899027203913298-11954270657760967272-codesite-noreply=google.com@googlecode.com> <0-3425899027203913298-11954270657760967272-codesite-noreply=google.com@googlecode.com> Message-ID: <8-3425899027203913298-11954270657760967272-codesite-noreply=google.com@googlecode.com> Comment #8 on issue 602 by allber... at gmail.com: xmonad hangs when clickJustFocuses = False and the user clicks outside of the focused window while a submap is active. https://code.google.com/p/xmonad/issues/detail?id=602 handleEventHook is used when you are running from the main loop. This is actually not ideal, as submaps don't really want to be mixed into the main loop; reworking with the handleEventHook has several potential difficulties some of which you have already encountered. A potentially worse issue is that the main loop does not expect to be running under an existing keyboard grab, as it would need to in this case; I don't know offhand if this will be a problem, and didn't think about it in my initial response --- which is kinda bad as ignoring things like that is how we get extensions that hang or crash xmonad. :/ There is the additional issue that, since you're processing from handleEventHook, you don't get to deal with events that interrupt your submap --- exactly the problem you are trying to solve here. Switching window focus with the mouse in the middle of a key sequence that affects the focused window may lead to unexpected results and user confusion. This is why I brought up the third alternative. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings From codesite-noreply at google.com Thu Apr 30 17:24:41 2015 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Thu, 30 Apr 2015 17:24:41 +0000 Subject: [xmonad] Issue 603 in xmonad: Problems with toggling focus on Chrome In-Reply-To: <4-3425899027203913298-3827064008373761146-codesite-noreply=google.com@googlecode.com> References: <4-3425899027203913298-3827064008373761146-codesite-noreply=google.com@googlecode.com> <0-3425899027203913298-3827064008373761146-codesite-noreply=google.com@googlecode.com> Message-ID: <5-3425899027203913298-3827064008373761146-codesite-noreply=google.com@googlecode.com> Updates: Status: Verified Owner: allber... at gmail.com Comment #5 on issue 603 by allber... at gmail.com: Problems with toggling focus on Chrome https://code.google.com/p/xmonad/issues/detail?id=603 (No comment was entered for this change.) -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings From alainbe at free.fr Thu Apr 30 19:03:47 2015 From: alainbe at free.fr (Alain Bertrand) Date: Thu, 30 Apr 2015 21:03:47 +0200 Subject: [xmonad] xmonad in debian 8 Message-ID: <55427C93.6000001@free.fr> Hi all, Since I upgraded my laptop to debian 8 (desktop is linuxmint 17.1), I encounter several dysfunctions (ugly fonts, quite long freezes and the like). Anyone else having the same problems here ? TIA Alain