From talw10 at gmail.com Wed Dec 2 08:11:01 2015 From: talw10 at gmail.com (Tal Walter) Date: Wed, 2 Dec 2015 10:11:01 +0200 Subject: [xmonad] How to have separate layout sets per screen in XMonad? Message-ID: Hi all! Is it possible to define 2 separate layout sets one per monitor in use? (not one per workspace) The use case is basically to have layouts with a master area on the left side for my right monitor, and the same layouts only 'reflected horizontally' (using Layout.Reflect) on my left monitor (i.e. master area on the right), so that, overall, the master areas are always in the center of the total estate of the 2 monitors. A solution that has separate layout sets per screen should be more than enough for this. I have a vague memory of finding such a module way back when, but I've went through the entirety of xmonad-contrib recently (looked at xmonad-extras as well) and didn't find a solution for this. There are separate layouts per workspace, and having separate workspaces per screen, but I want to switch between the 2 monitors on the fly and have consistent layouts as described above. So this solution won't work. In case I'm not missing any module in contrib, could someone please point me in a good starting direction as to how to implement such a thing? Any help is greatly appreciated! -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurnevsky at gmail.com Wed Dec 2 08:40:04 2015 From: kurnevsky at gmail.com (=?UTF-8?B?0JXQstCz0LXQvdC40Lkg0JrRg9GA0L3QtdCy0YHQutC40Lk=?=) Date: Wed, 2 Dec 2015 11:40:04 +0300 Subject: [xmonad] UpdatePointer bugfix Message-ID: Hi all. I fixed bug in UpdatePointer module - sometimes cursor was stuck in one of the corners. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: update-pointer-bugfix.dpatch Type: application/octet-stream Size: 2204 bytes Desc: not available URL: From allbery.b at gmail.com Wed Dec 2 13:44:33 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 2 Dec 2015 08:44:33 -0500 Subject: [xmonad] How to have separate layout sets per screen in XMonad? In-Reply-To: References: Message-ID: On Wed, Dec 2, 2015 at 3:11 AM, Tal Walter wrote: > In case I'm not missing any module in contrib, could someone please point > me in a good starting direction as to how to implement such a thing? This could be done with a layout modifier similar to onWorkspace, but you'll need to look in the StackSet for the workspace tag being laid out and determine what ScreenID it is currently on: that information is not passed to the LayoutHook. (xmonad-contrib in git has PerScreen but that triggers by screen width, not screen ID.) -- 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 talw10 at gmail.com Thu Dec 3 09:25:36 2015 From: talw10 at gmail.com (Tal Walter) Date: Thu, 3 Dec 2015 11:25:36 +0200 Subject: [xmonad] How to have separate layout sets per screen in XMonad? In-Reply-To: References: Message-ID: Thanks Brandon! Using the PerScreen module, I simply switched the condition from being on the screen width, to being on the screen x coordinate (which obviously differs between the left and right screens). However each time a new layout is returned (i.e. each time I switch screens) the index of the current selected layout from the layouts in the set is being reset. That is to be expected because there is no way of knowing apriori that the 2 layouts will have an equal amount of items, but in my case the 2 layout sets are symmetrical, therefore I would like to stay consistent with current selected layout index in the layout set. I tried looking around the Workspace ADT and the runLayout func but can't find a way to get to such an index. Is it feasible in a simple manner? I attached the code that I currently use. Any help is yet again, greatly appreciated! Thanks! On Wed, Dec 2, 2015 at 3:44 PM, Brandon Allbery wrote: > On Wed, Dec 2, 2015 at 3:11 AM, Tal Walter wrote: > >> In case I'm not missing any module in contrib, could someone please point >> me in a good starting direction as to how to implement such a thing? > > > This could be done with a layout modifier similar to onWorkspace, but > you'll need to look in the StackSet for the workspace tag being laid out > and determine what ScreenID it is currently on: that information is not > passed to the LayoutHook. (xmonad-contrib in git has PerScreen but that > triggers by screen width, not screen ID.) > > -- > 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: ifRightOf.hs Type: text/x-haskell Size: 1657 bytes Desc: not available URL: From miles at milessabin.com Thu Dec 3 10:01:16 2015 From: miles at milessabin.com (Miles Sabin) Date: Thu, 3 Dec 2015 10:01:16 +0000 Subject: [xmonad] Dual monitor hotplug issue Message-ID: Hi folks, I have laptop which is usually connected to a large external monitor. When it's connected, the external monitor is configured as the X primary using Xrandr. When I disconnect the external monitor the X configuration is automatically updated using autorandr, turning off the external monitor and setting the laptop panel as the primary. The switch of primary causes xmobar to automatically switch from the external monitor to the laptop panel, which is what I want. Unfortunately, a lot of windows are also moved onto the workspace which is visible on the laptop panel. Some of these are from the workspace which was visible on the monitor which has just been removed, but others are from workspaces which weren't visible on either the external or the laptop panel. How would I disable this behaviour? I want the primary to switch to the laptop panel, but I would like windows in workspaces that were on the disconnected monitor to stay part of their now invisible workspaces. This is with xmonad 0.11. Cheers, Miles -- Miles Sabin tel: +44 7813 944 528 skype: milessabin gtalk: miles at milessabin.com http://milessabin.com/blog http://twitter.com/milessabin From cocii at gmx.de Thu Dec 3 13:37:21 2015 From: cocii at gmx.de (=?UTF-8?Q?=22Peter_Krau=C3=9F=22?=) Date: Thu, 3 Dec 2015 14:37:21 +0100 Subject: [xmonad] Alt+Tab on a per workspace basis. Message-ID: An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Thu Dec 3 14:16:12 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Thu, 3 Dec 2015 09:16:12 -0500 Subject: [xmonad] Dual monitor hotplug issue In-Reply-To: References: Message-ID: On Thu, Dec 3, 2015 at 5:01 AM, Miles Sabin wrote: > Unfortunately, a lot of windows are also moved onto the workspace > which is visible on the laptop panel. Some of these are from the > workspace which was visible on the monitor which has just been > removed, but others are from workspaces which weren't visible on > either the external or the laptop panel. > Are you running a compositing manager? xmonad does not move windows around in that case, but compositing managers often seem to think it does; if I immediately kill the compositing manager, things go back where they should be. (Depending on my xmonad config, I can also sometimes trigger this with mod-q.) Oddly, if I do not immediately kill it, xmonad seems to adopt the new configuration (probably when the logHook runs or something). -- 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 miles at milessabin.com Thu Dec 3 15:17:46 2015 From: miles at milessabin.com (Miles Sabin) Date: Thu, 3 Dec 2015 15:17:46 +0000 Subject: [xmonad] Dual monitor hotplug issue In-Reply-To: References: Message-ID: On Thu, Dec 3, 2015 at 2:16 PM, Brandon Allbery wrote: > On Thu, Dec 3, 2015 at 5:01 AM, Miles Sabin wrote: >> >> Unfortunately, a lot of windows are also moved onto the workspace >> which is visible on the laptop panel. Some of these are from the >> workspace which was visible on the monitor which has just been >> removed, but others are from workspaces which weren't visible on >> either the external or the laptop panel. > > > Are you running a compositing manager? No, I'm not ... Xmonad standalone from lightdm via xmonad-session. Cheers, Miles -- Miles Sabin tel: +44 7813 944 528 skype: milessabin gtalk: miles at milessabin.com http://milessabin.com/blog http://twitter.com/milessabin From tuncer.ayaz at gmail.com Thu Dec 3 19:47:19 2015 From: tuncer.ayaz at gmail.com (Tuncer Ayaz) Date: Thu, 3 Dec 2015 20:47:19 +0100 Subject: [xmonad] New release to go with 7.10.2 In-Reply-To: References: Message-ID: So, who's in charge of cutting a release and how do we coordinate release notes with the suggested config examples? It seems there's nobody who feels they have the ball to run with, if that makes any sense. I'm still willing to help out with the release announcement as needed. From mlists at pmade.com Thu Dec 3 20:31:42 2015 From: mlists at pmade.com (Peter Jones) Date: Thu, 03 Dec 2015 13:31:42 -0700 Subject: [xmonad] Alt+Tab on a per workspace basis. References: Message-ID: <87r3j32s0h.fsf@pmade.com> "Peter Krau?" writes: > I would like to mimic Window's Alt+Tab behaviour in XMonad on a > per-workspace basis: Pressing Alt+Tab should focus the window on the > current workspace, that most recently had the focus on that workspace. > I can use GroupNavigation's "nextMatch History (return True)" but then > it also switches workspaces. I would need something like: > nextMatch History (window's workspace == current workspace) > Sadly I am not a Haskell guy, so I can not figure out how to create > such a query for. Could someone help me? Or maybe tell me if there is > a more easy solution? I would bind Alt+Tab to: windows W.focusDown -- Peter Jones, Founder, Devalot.com Defending the honor of good code From mlists at pmade.com Thu Dec 3 20:34:35 2015 From: mlists at pmade.com (Peter Jones) Date: Thu, 03 Dec 2015 13:34:35 -0700 Subject: [xmonad] New release to go with 7.10.2 References: Message-ID: <87lh9b2rvo.fsf@pmade.com> Tuncer Ayaz writes: > So, who's in charge of cutting a release and how do we coordinate > release notes with the suggested config examples? It seems there's > nobody who feels they have the ball to run with, if that makes any > sense. > > I'm still willing to help out with the release announcement as needed. I still think we need to have someone appointed as a release manager who can coordinate getting all the pieces in place (e.g., updating docs, etc.) and making the actual release. I previously volunteered for this position and I stand by that. -- Peter Jones, Founder, Devalot.com Defending the honor of good code From allbery.b at gmail.com Fri Dec 4 04:09:00 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Thu, 3 Dec 2015 23:09:00 -0500 Subject: [xmonad] Alt+Tab on a per workspace basis. In-Reply-To: References: Message-ID: On Thu, Dec 3, 2015 at 8:37 AM, "Peter Krau?" wrote: > Hello! > > I would like to mimic Window's Alt+Tab behaviour in XMonad on a > per-workspace basis: Pressing Alt+Tab should focus the window on the > current workspace, that most recently had the focus on that workspace. > I can use GroupNavigation's "nextMatch History (return True)" but then it > also switches workspaces. I would need something like: > > nextMatch History (window's workspace == current workspace) > > > Sadly I am not a Haskell guy, so I can not figure out how to create such a > query for. Could someone help me? Or maybe tell me if there is a more easy > solution? > sameWorkspace = do nw <- ask -- window being matched against liftX $ do ws <- gets windowset return $ maybe False (== currentTag ws) (findTag nw ws) -- 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 allbery.b at gmail.com Fri Dec 4 04:13:00 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Thu, 3 Dec 2015 23:13:00 -0500 Subject: [xmonad] How to have separate layout sets per screen in XMonad? In-Reply-To: References: Message-ID: On Thu, Dec 3, 2015 at 4:25 AM, Tal Walter wrote: > Is it feasible in a simple manner? > I attached the code that I currently use. > There is no such index. The layout is a function, it doesn't keep an index. This is also why there is no PreviousLayout message matching NextLayout. -- 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 talw10 at gmail.com Fri Dec 4 08:21:18 2015 From: talw10 at gmail.com (Tal Walter) Date: Fri, 4 Dec 2015 10:21:18 +0200 Subject: [xmonad] How to have separate layout sets per screen in XMonad? In-Reply-To: References: Message-ID: I see. Thanks anyway! The partial solution is great as well! On Fri, Dec 4, 2015 at 6:13 AM, Brandon Allbery wrote: > On Thu, Dec 3, 2015 at 4:25 AM, Tal Walter wrote: > >> Is it feasible in a simple manner? >> I attached the code that I currently use. >> > > There is no such index. The layout is a function, it doesn't keep an > index. This is also why there is no PreviousLayout message matching > NextLayout. > > -- > 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 byorgey at gmail.com Mon Dec 7 21:42:18 2015 From: byorgey at gmail.com (Brent Yorgey) Date: Mon, 07 Dec 2015 21:42:18 +0000 Subject: [xmonad] New release to go with 7.10.2 In-Reply-To: <87lh9b2rvo.fsf@pmade.com> References: <87lh9b2rvo.fsf@pmade.com> Message-ID: Sorry, I had offered to help but I don't really have a lot of time for it. I did set up automated builds on travis-ci, though haven't yet figured out how to get the xmonad-contrib build to use the git HEAD version of xmonad. I hope to iron that out soon. Peter, if you are willing to act as a release manager I think you should just go for it. I am adding you to the xmonad organization on github. Let me know how I can help. On Thu, Dec 3, 2015 at 2:35 PM Peter Jones wrote: > Tuncer Ayaz > writes: > > So, who's in charge of cutting a release and how do we coordinate > > release notes with the suggested config examples? It seems there's > > nobody who feels they have the ball to run with, if that makes any > > sense. > > > > I'm still willing to help out with the release announcement as needed. > > I still think we need to have someone appointed as a release manager who > can coordinate getting all the pieces in place (e.g., updating docs, > etc.) and making the actual release. I previously volunteered for this > position and I stand by that. > > -- > Peter Jones, Founder, Devalot.com > Defending the honor of good code > > _______________________________________________ > 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 Mon Dec 7 21:44:19 2015 From: byorgey at gmail.com (Brent Yorgey) Date: Mon, 07 Dec 2015 21:44:19 +0000 Subject: [xmonad] UpdatePointer bugfix In-Reply-To: References: Message-ID: Hi, xmonad development has recently moved to github, under github.com/xmonad --- would you mind resubmitting this as a pull request on github? Sorry for the confusion. If you are not familiar with git or github I could port the patch for you. -Brent On Wed, Dec 2, 2015 at 2:40 AM ??????? ?????????? wrote: > Hi all. I fixed bug in UpdatePointer module - sometimes cursor was stuck > in one of the corners. > _______________________________________________ > 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 mlists at pmade.com Mon Dec 7 21:53:27 2015 From: mlists at pmade.com (Peter Jones) Date: Mon, 07 Dec 2015 14:53:27 -0700 Subject: [xmonad] New release to go with 7.10.2 References: <87lh9b2rvo.fsf@pmade.com> Message-ID: <8737ve9b8o.fsf@pmade.com> Brent Yorgey writes: > Peter, if you are willing to act as a release manager I think you should > just go for it. I am adding you to the xmonad organization on github. Let > me know how I can help. Sounds great. I'll start working through the release management section of the TODO file tomorrow. Once I'm ready, I'll ask for help from people that have the appropriate credentials to update resources such as xmonad.org, IRC, hackage, etc. -- Peter Jones, Founder, Devalot.com Defending the honor of good code From mlists at pmade.com Mon Dec 7 22:05:10 2015 From: mlists at pmade.com (Peter Jones) Date: Mon, 07 Dec 2015 15:05:10 -0700 Subject: [xmonad] New release to go with 7.10.2 References: <87lh9b2rvo.fsf@pmade.com> Message-ID: <87wpsp9ap5.fsf@pmade.com> Brent Yorgey writes: > Peter, if you are willing to act as a release manager I think you should > just go for it. I am adding you to the xmonad organization on github. Let > me know how I can help. I think we'll need a "team" configured on Github to grant write access to at least the xmonad and xmonad-contrib repositories. At the very least I'd like to be able to change the .cabal file and tag releases. Thanks. -- Peter Jones, Founder, Devalot.com Defending the honor of good code From tuncer.ayaz at gmail.com Tue Dec 8 11:45:58 2015 From: tuncer.ayaz at gmail.com (Tuncer Ayaz) Date: Tue, 8 Dec 2015 12:45:58 +0100 Subject: [xmonad] New release to go with 7.10.2 In-Reply-To: <8737ve9b8o.fsf@pmade.com> References: <87lh9b2rvo.fsf@pmade.com> <8737ve9b8o.fsf@pmade.com> Message-ID: On 7 December 2015 at 22:53, Peter Jones wrote: > Brent Yorgey writes: > > Peter, if you are willing to act as a release manager I think you > > should just go for it. I am adding you to the xmonad organization > > on github. Let me know how I can help. > > Sounds great. > > I'll start working through the release management section of the > TODO file tomorrow. Once I'm ready, I'll ask for help from people > that have the appropriate credentials to update resources such as > xmonad.org, IRC, hackage, etc. Excellent! Besides more prominently advertising the use of the built-in prompt modules (e.g. as a dmenu replacement), what else should be highlighted in the release notes? It's been a while since the last release, and I surely don't remember all things worth a mention. So, let's collect noteworthy items. From mlists at pmade.com Tue Dec 8 23:45:07 2015 From: mlists at pmade.com (Peter Jones) Date: Tue, 08 Dec 2015 16:45:07 -0700 Subject: [xmonad] Preparing for v0.12 Release Message-ID: <87h9js8pz0.fsf@pmade.com> This is a notice that I'm actively working on the 0.12 release and a call to action for the xmonad community. As part of this release I've reformatted the README files as Markdown for nicer display on both Hackage and GitHub. I've also created CHANGES.md files since Hackage supports package change logs. Please take a moment to review these files, especially the change logs. Let me know if anything is missing or incorrect. I believe we should be able to make a release this week. That means you don't have much time to review these files. https://github.com/pjones/xmonad/tree/release-0.12 https://github.com/pjones/xmonad-contrib/tree/release-0.12 Thanks! -- Peter Jones, Founder, Devalot.com Defending the honor of good code From vogt.adam at gmail.com Tue Dec 8 23:59:18 2015 From: vogt.adam at gmail.com (adam vogt) Date: Tue, 8 Dec 2015 18:59:18 -0500 Subject: [xmonad] Preparing for v0.12 Release In-Reply-To: <87h9js8pz0.fsf@pmade.com> References: <87h9js8pz0.fsf@pmade.com> Message-ID: Hi Peter, Thanks for taking this on. It seems like CHANGES.md is a slightly less detailed version of https://wiki.haskell.org/Xmonad/Notable_changes_since_0.11 . Probably they could reference each other, if they both should continue to exist. Cheers, Adam On Dec 8, 2015 6:45 PM, "Peter Jones" wrote: > This is a notice that I'm actively working on the 0.12 release and a > call to action for the xmonad community. > > As part of this release I've reformatted the README files as Markdown > for nicer display on both Hackage and GitHub. I've also created > CHANGES.md files since Hackage supports package change logs. > > Please take a moment to review these files, especially the change logs. > Let me know if anything is missing or incorrect. I believe we should be > able to make a release this week. That means you don't have much time > to review these files. > > https://github.com/pjones/xmonad/tree/release-0.12 > > https://github.com/pjones/xmonad-contrib/tree/release-0.12 > > Thanks! > > -- > Peter Jones, Founder, Devalot.com > Defending the honor of good code > > _______________________________________________ > 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 mlists at pmade.com Wed Dec 9 00:11:40 2015 From: mlists at pmade.com (Peter Jones) Date: Tue, 08 Dec 2015 17:11:40 -0700 Subject: [xmonad] Preparing for v0.12 Release References: <87h9js8pz0.fsf@pmade.com> Message-ID: <87d1ug8oqr.fsf@pmade.com> adam vogt writes: > It seems like CHANGES.md is a slightly less detailed version of > https://wiki.haskell.org/Xmonad/Notable_changes_since_0.11 . Probably they > could reference each other, if they both should continue to exist. It probably doesn't make a lot of sense for both to exist. I personally prefer CHANGES.md since: 1) Hackage will show the file, and Hackage seems like a great place to display a list of changes 2) Being part of the repository, we could ask everyone to make appropriate updates to the CHANGES.md file with each pull request/patch That said, I'm open to other ideas. I'll incorporate details from the wiki into CHANGES.md file for now, assuming that the wiki version is going to die. -- Peter Jones, Founder, Devalot.com Defending the honor of good code From mlists at pmade.com Wed Dec 9 20:03:35 2015 From: mlists at pmade.com (Peter Jones) Date: Wed, 09 Dec 2015 13:03:35 -0700 Subject: [xmonad] Preparing for v0.12 Release References: <87h9js8pz0.fsf@pmade.com> Message-ID: <87h9jr75k8.fsf@pmade.com> adam vogt writes: > It seems like CHANGES.md is a slightly less detailed version of > https://wiki.haskell.org/Xmonad/Notable_changes_since_0.11 . Probably they > could reference each other, if they both should continue to exist. I've pulled in the notes from the wiki and added additional details: https://github.com/pjones/xmonad-contrib/blob/release-0.12/CHANGES.md -- Peter Jones, Founder, Devalot.com Defending the honor of good code From mlists at pmade.com Wed Dec 9 20:05:02 2015 From: mlists at pmade.com (Peter Jones) Date: Wed, 09 Dec 2015 13:05:02 -0700 Subject: [xmonad] New release to go with 7.10.2 References: <87lh9b2rvo.fsf@pmade.com> <8737ve9b8o.fsf@pmade.com> Message-ID: <87d1uf75ht.fsf@pmade.com> Tuncer Ayaz writes: > Besides more prominently advertising the use of the built-in prompt > modules (e.g. as a dmenu replacement), what else should be highlighted > in the release notes? It's been a while since the last release, and I > surely don't remember all things worth a mention. So, let's collect > noteworthy items. Tuncer, please take a look at what I have so far and let me know how you want to prominently display the use of Prompt: https://github.com/pjones/xmonad-contrib/blob/release-0.12/CHANGES.md -- Peter Jones, Founder, Devalot.com Defending the honor of good code From mlists at pmade.com Wed Dec 9 21:33:02 2015 From: mlists at pmade.com (Peter Jones) Date: Wed, 09 Dec 2015 14:33:02 -0700 Subject: [xmonad] Is anyone maintaining the development snapshots? Message-ID: <878u5371f5.fsf@pmade.com> The xmonad README mentions the following "development snapshot" links: http://code.haskell.org/xmonad/xmonad.tar.gz http://code.haskell.org/XMonadContrib/xmc.tar.gz Is someone creating these manually or were they nightly snapshots from Darcs? If these aren't actively maintained (and generated from the Git repo) then I suggest we remove them from the README. -- Peter Jones, Founder, Devalot.com Defending the honor of good code From vogt.adam at gmail.com Thu Dec 10 00:35:14 2015 From: vogt.adam at gmail.com (adam vogt) Date: Wed, 9 Dec 2015 19:35:14 -0500 Subject: [xmonad] Is anyone maintaining the development snapshots? In-Reply-To: <878u5371f5.fsf@pmade.com> References: <878u5371f5.fsf@pmade.com> Message-ID: They were generated by darcs wherever somebody pushed a patch. They are out of date now. Github has ways to download the repo as an archive, but there might not be much point in keeping that method since I understand git is installed much more widely than darcs. On Dec 9, 2015 4:33 PM, "Peter Jones" wrote: > The xmonad README mentions the following "development snapshot" links: > > http://code.haskell.org/xmonad/xmonad.tar.gz > > http://code.haskell.org/XMonadContrib/xmc.tar.gz > > Is someone creating these manually or were they nightly snapshots from > Darcs? If these aren't actively maintained (and generated from the Git > repo) then I suggest we remove them from the README. > > -- > Peter Jones, Founder, Devalot.com > Defending the honor of good code > > _______________________________________________ > 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 mlists at pmade.com Thu Dec 10 00:52:15 2015 From: mlists at pmade.com (Peter Jones) Date: Wed, 09 Dec 2015 17:52:15 -0700 Subject: [xmonad] Is anyone maintaining the development snapshots? References: <878u5371f5.fsf@pmade.com> Message-ID: <87wpsn5dmo.fsf@pmade.com> adam vogt writes: > They were generated by darcs wherever somebody pushed a patch. They are out > of date now. Github has ways to download the repo as an archive, but there > might not be much point in keeping that method since I understand git is > installed much more widely than darcs. I thought about using GitHub's archive feature, but it generates (and forces) https links. Unfortunately, cabal doesn't support them. -- Peter Jones, Founder, Devalot.com Defending the honor of good code From vogt.adam at gmail.com Thu Dec 10 00:59:46 2015 From: vogt.adam at gmail.com (adam vogt) Date: Wed, 9 Dec 2015 19:59:46 -0500 Subject: [xmonad] UpdatePointer bugfix In-Reply-To: References: Message-ID: Darcs lets you display a message when people "darcs get", which could mention the new repo. Maybe that would have prevented this confusion. On Dec 7, 2015 4:44 PM, "Brent Yorgey" wrote: > Hi, xmonad development has recently moved to github, under > github.com/xmonad --- would you mind resubmitting this as a pull request > on github? Sorry for the confusion. If you are not familiar with git or > github I could port the patch for you. > > -Brent > > On Wed, Dec 2, 2015 at 2:40 AM ??????? ?????????? > wrote: > >> Hi all. I fixed bug in UpdatePointer module - sometimes cursor was stuck >> in one of the corners. >> _______________________________________________ >> 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 tuncer.ayaz at gmail.com Thu Dec 10 18:48:18 2015 From: tuncer.ayaz at gmail.com (Tuncer Ayaz) Date: Thu, 10 Dec 2015 19:48:18 +0100 Subject: [xmonad] New release to go with 7.10.2 In-Reply-To: <87d1uf75ht.fsf@pmade.com> References: <87lh9b2rvo.fsf@pmade.com> <8737ve9b8o.fsf@pmade.com> <87d1uf75ht.fsf@pmade.com> Message-ID: On 9 December 2015 at 21:05, Peter Jones wrote: > Tuncer Ayaz > writes: > > Besides more prominently advertising the use of the built-in > > prompt modules (e.g. as a dmenu replacement), what else should be > > highlighted in the release notes? It's been a while since the last > > release, and I surely don't remember all things worth a mention. > > So, let's collect noteworthy items. > > Tuncer, please take a look at what I have so far and let me know how > you want to prominently display the use of Prompt: > > https://github.com/pjones/xmonad-contrib/blob/release-0.12/CHANGES.md Nice, that looks comprehensive. Given all the other config enhancements, the best way to promote use of the prompt module(s) is a short sample config to include in the release notes. It should use the new config features and XMonad.Prompt.Shell in place of dmenu for M-p. From mlists at pmade.com Fri Dec 11 18:30:49 2015 From: mlists at pmade.com (Peter Jones) Date: Fri, 11 Dec 2015 11:30:49 -0700 Subject: [xmonad] Code Freeze for v0.12 and Time to Test! Message-ID: <87eges6dnq.fsf@pmade.com> Except for bug fixes, I'd like to call for a freeze on commits to the xmonad and xmonad-contrib repositories until we get a release out. At this point I think we have everything we need in place. Let's take advantage of the weekend and let as many people as possible test 0.12. Then on Monday I'll open pull requests from my repos and we can tag and release. For reference, the following repositories have the latest changes plus all of my documentation updates: https://github.com/pjones/xmonad/tree/release-0.12 https://github.com/pjones/xmonad-contrib/tree/release-0.12 I also put together a stand-alone repository to help me test xmonad and xmonad-contrib using GHC 7.10.2, 7.8.4, and 7.6.3. (We should plan on making another release in January to cover 7.10.3.) My testing repository can be found at: https://github.com/pjones/xmonad-test/tree/release-0.12 So, please go forth and read the docs and compile the code! -- Peter Jones, Founder, Devalot.com Defending the honor of good code From gansteed at gmail.com Sat Dec 12 04:00:57 2015 From: gansteed at gmail.com (gansteed) Date: Sat, 12 Dec 2015 04:00:57 +0000 Subject: [xmonad] Code Freeze for v0.12 and Time to Test! In-Reply-To: <87eges6dnq.fsf@pmade.com> References: <87eges6dnq.fsf@pmade.com> Message-ID: Actually, ArchLinux is using GHC 7.10.3 now. Peter Jones ?2015?12?12??? ??2:31??? > Except for bug fixes, I'd like to call for a freeze on commits to the > xmonad and xmonad-contrib repositories until we get a release out. > > At this point I think we have everything we need in place. Let's take > advantage of the weekend and let as many people as possible test 0.12. > Then on Monday I'll open pull requests from my repos and we can tag and > release. > > For reference, the following repositories have the latest changes plus > all of my documentation updates: > > https://github.com/pjones/xmonad/tree/release-0.12 > > https://github.com/pjones/xmonad-contrib/tree/release-0.12 > > I also put together a stand-alone repository to help me test xmonad and > xmonad-contrib using GHC 7.10.2, 7.8.4, and 7.6.3. (We should plan on > making another release in January to cover 7.10.3.) > > My testing repository can be found at: > > https://github.com/pjones/xmonad-test/tree/release-0.12 > > So, please go forth and read the docs and compile the code! > > -- > Peter Jones, Founder, Devalot.com > Defending the honor of good code > > _______________________________________________ > 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 mimi.vx at gmail.com Sat Dec 12 13:58:52 2015 From: mimi.vx at gmail.com (=?UTF-8?B?T25kxZllaiBTw7prdXA=?=) Date: Sat, 12 Dec 2015 14:58:52 +0100 Subject: [xmonad] Code Freeze for v0.12 and Time to Test! In-Reply-To: References: <87eges6dnq.fsf@pmade.com> Message-ID: in January/February maybe another release to cover 8.0.1 :) 7.10.3 is mainly bugfix ==> +- same results of test as 7.10.2 On 12 December 2015 at 05:00, gansteed wrote: > Actually, ArchLinux is using GHC 7.10.3 now. > > Peter Jones ?2015?12?12??? ??2:31??? >> >> Except for bug fixes, I'd like to call for a freeze on commits to the >> xmonad and xmonad-contrib repositories until we get a release out. >> >> At this point I think we have everything we need in place. Let's take >> advantage of the weekend and let as many people as possible test 0.12. >> Then on Monday I'll open pull requests from my repos and we can tag and >> release. >> >> For reference, the following repositories have the latest changes plus >> all of my documentation updates: >> >> https://github.com/pjones/xmonad/tree/release-0.12 >> >> https://github.com/pjones/xmonad-contrib/tree/release-0.12 >> >> I also put together a stand-alone repository to help me test xmonad and >> xmonad-contrib using GHC 7.10.2, 7.8.4, and 7.6.3. (We should plan on >> making another release in January to cover 7.10.3.) >> >> My testing repository can be found at: >> >> https://github.com/pjones/xmonad-test/tree/release-0.12 >> >> So, please go forth and read the docs and compile the code! >> >> -- >> Peter Jones, Founder, Devalot.com >> Defending the honor of good code >> >> _______________________________________________ >> 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 > From matt.g.d.walker at gmail.com Sun Dec 13 17:49:59 2015 From: matt.g.d.walker at gmail.com (Matt Walker) Date: Sun, 13 Dec 2015 12:49:59 -0500 Subject: [xmonad] `Status' Package [xmonad-contrib] Message-ID: Hello everyone, I've been using xmonad for a couple of months now, and there is something that has always bothered me, so I'm writing a package to fix it. [Problem Statement] Many people who use dzen2 do so with the help of Conky or other external programs. While nice, if would be better to be able to control it with XMonad in a nice way without them. This would require two things: more control over how information is outputted to dzen2 from xmonad than that afforded by DynamicLog, and ways of retrieving system information for xmonad to use. Specifically, we would want a flexible, extensible, and elegant solution, and one that works for more than just Dzen. I argue no such solution currently exists, and why this is a problem. [Evidence of Problem] People with advanced XMonad/Dzen2 setups often resort to using two different Dzen2 bars -- one for XMonad stuff that XMonad controls, and one that is piped output from something like Conky. Here are just a few examples I've found around the web: https://wiki.haskell.org/Xmonad/Config_archive/And1's_xmonad.hs (note the hacky (but effective) use of the DynamicLog PP facilities) https://wiki.haskell.org/Xmonad/Config_archive/Regalia's_xmonad.hs https://wiki.haskell.org/Xmonad/Config_archive/Thayer_Williams'_xmonad.hs https://wiki.haskell.org/Xmonad/Config_archive/avendael's_xmonad.hs http://thinkingeek.com/2011/11/21/simple-guide-configure-xmonad-dzen2-conky/ https://github.com/davidbeckingsale/xmonad-config/blob/master/xmonad.hs In each of these cases, the status bar has two parts: one part controlled by XMonad that deals with the WM state, and another part controlled by Conky that contains the system state. The premise of my argument is basically that this is undesirable, and all information should be available from, and outputted from, xmonad. We have a Haskell environment, and we are completely by-passing it! [Probable Cause of Problem] DynamicLog's PP facility is extremely useful if you want to quickly get a statusbar up quickly and with minimal customization. But it quickly becomes too weak to do anything fancy with, without getting very hacky. For example, say I wanted my current layout and window-name information printed in the middle of the bar, and my list of workspaces printed on the left side of the bar. This is difficult to achieve with the current tools -- one must be aware of the formatting characters when performing the translation if one wants the text to be correctly justified/centred. One must be quite familiar with which parts of the PP get outputted when and how they are put together (since we want two fields to be output to the same region, but centring them both would make them overlap.) This makes for a brittle and non-general solution to the problem. The problem is that DynamicLog's PP facility is not extensible in any elegant way. You have to know how the whole thing works to be able to extend it, even in minor ways. Modifications to it are neither composable, nor factorable -- I can't just add or remove customizations without it probably breaking. [Proposed Solution] I propose a new solution. The code for this solution is located here: https://github.com/Fizzixnerd/xmonad-config/tree/master/site-haskell/src/XMonad/Hooks/DynamicLog/Status . I haven't yet spun off the code in that subdirectory into its own repo. Right now, the whole repo is an unholy Frankenstein's monster of personal configuration, failed attempts, and worthwhile work. Most of the good stuff is in XMonad.Hooks.DynamicLog.Status though. The main idea is that we defined a new type, StatusText which has three bits: a prefix, a suffix, and some content. The actual stuff you want to display goes in the content section, while the prefix and suffix hold the markup information. Here is a brief summary of the type: type Status b a = Writer (b, Dual b) a type StatusText = Status [T.Text] T.Text where Dual is defined in Data.Monoid. And that's it! We get a Functor and Writer Monad for free out of this definition, clearly. The Dual is there so that if you have something like hello there!, then the wrapping happens in the correct order. That is, you don't end up with hello there!. We define the `length' of a StatusText to be the length of the content. This allows us to calculate offsets within the status bar without having to strip away all the markup. I have a library included in Status.DZen2 (name change is coming to get rid of the capital Z). It contains combinators and so on for marking up StatusText using all the dzen2 commands, all from within XMonad. Exciting! I plan to make a universal interface and a fancy interface: the universal interface will contain all commands common to dzen2, xmobar, and possibly taffybar. In this way, it will be possible to swap out your statusbar without everything breaking. Maybe I'll abandon this part, but let me know if it sounds cool to you. There are also facilities similar to those found in XMonad.Util.Logger for making StatusTexts from shell commands. These are found in Status.StatusText.Dynamic. The point of this is so that the formatting of the information can be cleanly separated from the retrieval of the information. This makes things more composable, and doesn't have use relying on brittle solutions. However, you can still just plug in your conky stuff and pipe it through xmonad if you want to just get it up and running to see what it's like. I will be adding a few `standard' StatusTexts in Status.System. I have replicated the facilities found in XMonad.Hooks.DynamicLog's PP's by factoring out the different parts of the PP and then wrapping those in StatusTexts in Status.X. Big ups to the creator of DynamicLog's PPs. They are a fantastic idea within the domain of their applicability, and I used a lot of the code from them. I will be spending the coming days cleaning up the codebase and getting it ready to be submitted for possible inclusion in xmonad-contrib. I don't think it even compiles right now, but past versions of it have worked so I'm not super worried about there being a fundamental flaw in it or whatever. There are some examples using battery in Status.System of composing a StatusText to format content using the monadic interface in Status.DZen2.Fancy. Finally, you take your StatusTexts, stick them in a list (one for the left, middle, and right side of the bar respectively), and then render them to a string. This is the part that isn't quite done yet, but it's also probably the most straightforward. More on that later. Obviously, this package is best used with XMonad.Util.Timer, since you probably want your uptime and stuff to actually update properly with time, and not just on X events. [License] Its currently GPLv3, but I have no qualms about changing it once its ready. [Conclusion] I'd love to hear some feedback on this. Does anyone even care? Maybe this is better left as just a personal package for myself. I have no idea. I just felt it solved a rather general problem, and so could possibly be of use to other people. If it helps reduce the (in my opinion) ugly hacky use of Conky and 2+ dzen bars, then I think that's pretty good. Let me know! Sincerely, Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From lewo at abesis.fr Sun Dec 13 18:40:01 2015 From: lewo at abesis.fr (lewo at abesis.fr) Date: Sun, 13 Dec 2015 19:40:01 +0100 Subject: [xmonad] [patch] X.P.Window: window selector for the prompt and BringToMaster action Message-ID: <87egeq42gu.fsf@tilia.home> Hi all, Here is the commit message of attached patch: * X.P.Window: window selector for the prompt and BringToMaster action - The set of windows proposed by the prompt can be parametrized. Two helper functions are currently defined. One for selecting all available windows and another one for selecting all windows of the current workspace. - Add BringToMaster action which brings the selected window to the current workspace and set it as master. - windowPromptGoto, windowPromptBring, windowPromptBringCopy are marked as deprecated since they can be realized by the more generic windowPrompt function. For instance, "windowPromptGoto prompt" can be easily replaced by "windowPrompt prompt Goto allWindows". Cheers, Antoine. -------------- next part -------------- A non-text attachment was scrubbed... Name: windowPrompt.dpatch Type: test/x-patch Size: 42074 bytes Desc: not available URL: From allbery.b at gmail.com Sun Dec 13 19:24:36 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Sun, 13 Dec 2015 14:24:36 -0500 Subject: [xmonad] [patch] X.P.Window: window selector for the prompt and BringToMaster action In-Reply-To: <87egeq42gu.fsf@tilia.home> References: <87egeq42gu.fsf@tilia.home> Message-ID: On Sun, Dec 13, 2015 at 1:40 PM, wrote: > > Here is the commit message of attached patch: Given that we've moved to github, you might want to resubmit this as a pull request. -- 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 lewo at abesis.fr Sun Dec 13 19:42:46 2015 From: lewo at abesis.fr (lewo at abesis.fr) Date: Sun, 13 Dec 2015 20:42:46 +0100 Subject: [xmonad] [patch] X.P.Window: window selector for the prompt and BringToMaster action In-Reply-To: References: <87egeq42gu.fsf@tilia.home> Message-ID: <87bn9u3zk9.fsf@tilia.home> Brandon Allbery writes: > On Sun, Dec 13, 2015 at 1:40 PM, wrote: > >> >> Here is the commit message of attached patch: > > > Given that we've moved to github, you might want to resubmit this as a pull > request. Done. We should quickly update https://wiki.haskell.org/Xmonad/xmonad_development_tutorial since it's still mentionning the darcs XmonadContrib repo. Antoine. From mlists at pmade.com Mon Dec 14 16:05:30 2015 From: mlists at pmade.com (Peter Jones) Date: Mon, 14 Dec 2015 09:05:30 -0700 Subject: [xmonad] Code Freeze for v0.12 and Time to Test! References: <87eges6dnq.fsf@pmade.com> Message-ID: <87oadt3tit.fsf@pmade.com> If someone can explicitly state that all the xmonad + xmonad-contrib tests pass under 7.10.3 then I'm happy to add it to the tested compilers list in the cabal file. Ond?ej S?kup writes: > in January/February maybe another release to cover 8.0.1 :) > > 7.10.3 is mainly bugfix ==> +- same results of test as 7.10.2 -- Peter Jones, Founder, Devalot.com Defending the honor of good code From vrs+xmonad at synkretie.net Mon Dec 14 18:26:32 2015 From: vrs+xmonad at synkretie.net (vrs) Date: Mon, 14 Dec 2015 19:26:32 +0100 Subject: [xmonad] `Status' Package [xmonad-contrib] In-Reply-To: References: Message-ID: <145011759290.9363.8508066303118361091@synkretie.net> Quoting Matt Walker (2015-12-13 18:49:59) > [Evidence of Problem] > > People with advanced XMonad/Dzen2 setups often resort to using two > different Dzen2 bars -- one for XMonad stuff that XMonad controls, and one > that is piped output from something like Conky. Here are just a few > examples I've found around the web: > > https://wiki.haskell.org/Xmonad/Config_archive/And1's_xmonad.hs (note the > hacky (but effective) use of the DynamicLog PP facilities) > https://wiki.haskell.org/Xmonad/Config_archive/Regalia's_xmonad.hs > https://wiki.haskell.org/Xmonad/Config_archive/Thayer_Williams'_xmonad.hs > https://wiki.haskell.org/Xmonad/Config_archive/avendael's_xmonad.hs > http://thinkingeek.com/2011/11/21/simple-guide-configure-xmonad-dzen2-conky/ > https://github.com/davidbeckingsale/xmonad-config/blob/master/xmonad.hs > > In each of these cases, the status bar has two parts: one part controlled > by XMonad that deals with the WM state, and another part controlled by > Conky that contains the system state. The premise of my argument is > basically that this is undesirable, and all information should be available > from, and outputted from, xmonad. We have a Haskell environment, and we > are completely by-passing it! I have something similar (unpublished) with two xmobars, but I do this because I essentially ran out of space to display all the info I want to display. One top xmobar per screen that displays workspace info, current directory (heavily integrated with topicspaces) and window titles (that took some hacking), and a bottom one on the main screen for system info. > For example, say I wanted my current layout and window-name information > printed in the middle of the bar, and my list of workspaces printed on the > left side of the bar. This is difficult to achieve with the current tools > -- one must be aware of the formatting characters when performing the > translation if one wants the text to be correctly justified/centred. One > must be quite familiar with which parts of the PP get outputted when and > how they are put together (since we want two fields to be output to the > same region, but centring them both would make them overlap.) This makes > for a brittle and non-general solution to the problem. To add to this: xmobar doesn't interpret separators in the output piped to it at all. > The problem is that DynamicLog's PP facility is not extensible in any > elegant way. You have to know how the whole thing works to be able to > extend it, even in minor ways. Modifications to it are neither composable, > nor factorable -- I can't just add or remove customizations without it > probably breaking. Hm works for me? You just need to be able to use ppExtras, the rest can be entirely custom. I do agree that the code is quite specific to your status bar though. > We define the `length' of a StatusText to be the length of the content. > This allows us to calculate offsets within the status bar without having to > strip away all the markup. That is neat but it takes only an application of shorten in the right place, namely before adding all the markup. > I have a library included in Status.DZen2 (name change is coming to get rid > of the capital Z). It contains combinators and so on for marking up > StatusText using all the dzen2 commands, all from within XMonad. > Exciting! I plan to make a universal interface and a fancy interface: the > universal interface will contain all commands common to dzen2, xmobar, and > possibly taffybar. In this way, it will be possible to swap out your > statusbar without everything breaking. Maybe I'll abandon this part, but > let me know if it sounds cool to you. Well to be honest I would expect such a migration to involve a certain amount of work regardless of the way my xmonad output is formatted - for example I'd need to migrate all my system information scripts and maybe write some new ones. The formatting would be a minor problem. > [Conclusion] > > I'd love to hear some feedback on this. Does anyone even care? Maybe this > is better left as just a personal package for myself. I have no idea. I > just felt it solved a rather general problem, and so could possibly be of > use to other people. If it helps reduce the (in my opinion) ugly hacky use > of Conky and 2+ dzen bars, then I think that's pretty good. Let me know! I'm interested, but so far I see nothing that would make me migrate. The most difficult part for me as a relative haskell noob was to get getName to behave and generally get all the desired info out of xmonad in the first place. Formatting was verbose to do but not particularly difficult. Personally, the first place I'd improve would be the xmobar config parser (not applicable to your usecase). Cheers, vrs PS: since you're familiar with dzen and its syntax, you may want to look at this commit and check whether dzenstrip has a similar issue: From tuncer.ayaz at gmail.com Mon Dec 14 20:06:02 2015 From: tuncer.ayaz at gmail.com (Tuncer Ayaz) Date: Mon, 14 Dec 2015 21:06:02 +0100 Subject: [xmonad] Code Freeze for v0.12 and Time to Test! In-Reply-To: <87oadt3tit.fsf@pmade.com> References: <87eges6dnq.fsf@pmade.com> <87oadt3tit.fsf@pmade.com> Message-ID: On 14 December 2015 at 17:05, Peter Jones wrote: > If someone can explicitly state that all the xmonad + xmonad-contrib > tests pass under 7.10.3 then I'm happy to add it to the tested compilers > list in the cabal file. I didn't run tests, but fwiw I'm using xmonad + xmonad-contrib built with 7.10.3. From matt.g.d.walker at gmail.com Fri Dec 18 17:12:17 2015 From: matt.g.d.walker at gmail.com (Matt Walker) Date: Fri, 18 Dec 2015 12:12:17 -0500 Subject: [xmonad] Migrate from String to Data.Text [proposal] Message-ID: Hi everyone, I noticed that xmonad and xmonad-contrib both prefer to use of String = [Char] for their stringy data-types. This is probably a terrible idea. I cite some sources here, then outline their arguments below. http://www.alexeyshmalko.com/2015/haskell-string-types/ https://mail.haskell.org/pipermail/haskell-cafe/2014-June/114745.html __String is Bad__ 1) Char is a horribly inefficient representation of a character, being an entire machine word in length (at least 32 bits). Actually, it's worse: each Char takes up _two_ machine words in GHC, since it needs one to store GC information in. See the slide in the first link for more details. Data.Text stores the characters in compact arrays. 2) Lists are lazy, which makes their evaluation slower. You have to thunk on each character, which is pretty silly most of the time. Normally you want to read in at least _chunks_ of string all at once. Data.Text is strict, but Data.Text.Lazy exists and is (as you would assume) lazy when you need it. The long and the short of it is that [Char] is a suboptimal choice to use for anything except possibly short identifiers; Haskell (via GHC) is a compiled language, and yet performs orders of magnitudes worse than even Perl and Python on text processing when using Data.String. There is simply no good reason to use String when Text exists. __Alternatives__ The other alternative is ByteString. Although ByteString is a great type for binary data, and specifically for data exchange protocols, it seems that it would inappropriate in this situation, due to the replacement of most (if not all) instances being actual textual data, which obviously Text is optimized for. __Migration Issues__ Assuming we can agree that Text > String then, the main problem to switching would be the pain of migration, and whether this would be worth it. I argue it wouldn't be so bad, and is worth doing on principle alone. The LANGUAGE pragma of OverloadedStrings allows you to use String literals as Text literals, so that wouldn't be the main problem. The main issue is changing all the interfaces so they accept Text instead of String, and how this would impact existing user configs, and the xmonad-contrib archive. Every time you use ++ you would have to replace it with <>, the Monoid infix mappend operator. I doubt many people use : to build Strings, but in those instances those would have to be changed too. Finally, pattern matching on Strings like (x:xs) would break as well. All other functions would require changing from their String/List counterpart to the Text one. Since the names clash, one would have to import qualified as, for instance, T and call T.intersperse or whatever. It would be a non-trivial undertaking, but certainly doable. __Other Breaking Changes__ Are there other niggling issues that exist in the codebase that would cause breaking changes? Perhaps it would be a good idea to get a list of them all and see if it's worth breaking backwards compatibility to fix them all at once? I'm a purist when it comes to code, but I would like to hear what other people think, and just how angry they would be with this change. I have no idea as to what xmonad and xmonad-contrib's breaking changes policy is. Obviously I'm not proposing this change be undertaken for 0.13 -- I was aiming for more 0.14 or later. Let me know what you think. Sincerely, Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From byorgey at gmail.com Fri Dec 18 17:14:07 2015 From: byorgey at gmail.com (Brent Yorgey) Date: Fri, 18 Dec 2015 17:14:07 +0000 Subject: [xmonad] `Status' Package [xmonad-contrib] In-Reply-To: References: Message-ID: Sounds cool. I don't think I would personally use it, but I think you should submit it to xmonad-contrib regardless of whether anyone says they would use it. If it's there, then perhaps someone will find it. -Brent On Sun, Dec 13, 2015 at 11:50 AM Matt Walker wrote: > Hello everyone, > > I've been using xmonad for a couple of months now, and there is something > that has always bothered me, so I'm writing a package to fix it. > > [Problem Statement] > > Many people who use dzen2 do so with the help of Conky or other external > programs. While nice, if would be better to be able to control it with > XMonad in a nice way without them. This would require two things: more > control over how information is outputted to dzen2 from xmonad than that > afforded by DynamicLog, and ways of retrieving system information for > xmonad to use. Specifically, we would want a flexible, extensible, and > elegant solution, and one that works for more than just Dzen. I argue no > such solution currently exists, and why this is a problem. > > [Evidence of Problem] > > People with advanced XMonad/Dzen2 setups often resort to using two > different Dzen2 bars -- one for XMonad stuff that XMonad controls, and one > that is piped output from something like Conky. Here are just a few > examples I've found around the web: > > https://wiki.haskell.org/Xmonad/Config_archive/And1's_xmonad.hs (note the > hacky (but effective) use of the DynamicLog PP facilities) > https://wiki.haskell.org/Xmonad/Config_archive/Regalia's_xmonad.hs > https://wiki.haskell.org/Xmonad/Config_archive/Thayer_Williams'_xmonad.hs > https://wiki.haskell.org/Xmonad/Config_archive/avendael's_xmonad.hs > > http://thinkingeek.com/2011/11/21/simple-guide-configure-xmonad-dzen2-conky/ > https://github.com/davidbeckingsale/xmonad-config/blob/master/xmonad.hs > > In each of these cases, the status bar has two parts: one part controlled > by XMonad that deals with the WM state, and another part controlled by > Conky that contains the system state. The premise of my argument is > basically that this is undesirable, and all information should be available > from, and outputted from, xmonad. We have a Haskell environment, and we > are completely by-passing it! > > [Probable Cause of Problem] > > DynamicLog's PP facility is extremely useful if you want to quickly get a > statusbar up quickly and with minimal customization. But it quickly > becomes too weak to do anything fancy with, without getting very hacky. > > For example, say I wanted my current layout and window-name information > printed in the middle of the bar, and my list of workspaces printed on the > left side of the bar. This is difficult to achieve with the current tools > -- one must be aware of the formatting characters when performing the > translation if one wants the text to be correctly justified/centred. One > must be quite familiar with which parts of the PP get outputted when and > how they are put together (since we want two fields to be output to the > same region, but centring them both would make them overlap.) This makes > for a brittle and non-general solution to the problem. > > The problem is that DynamicLog's PP facility is not extensible in any > elegant way. You have to know how the whole thing works to be able to > extend it, even in minor ways. Modifications to it are neither composable, > nor factorable -- I can't just add or remove customizations without it > probably breaking. > > [Proposed Solution] > > I propose a new solution. The code for this solution is located here: > https://github.com/Fizzixnerd/xmonad-config/tree/master/site-haskell/src/XMonad/Hooks/DynamicLog/Status > . I haven't yet spun off the code in that subdirectory into its own repo. > Right now, the whole repo is an unholy Frankenstein's monster of personal > configuration, failed attempts, and worthwhile work. Most of the good > stuff is in XMonad.Hooks.DynamicLog.Status though. > > The main idea is that we defined a new type, StatusText which has three > bits: a prefix, a suffix, and some content. The actual stuff you want to > display goes in the content section, while the prefix and suffix hold the > markup information. > > Here is a brief summary of the type: > > type Status b a = Writer (b, Dual b) a > type StatusText = Status [T.Text] T.Text > > where Dual is defined in Data.Monoid. And that's it! We get a Functor > and Writer Monad for free out of this definition, clearly. The Dual is > there so that if you have something like hello > there!, then the wrapping happens in the correct order. > That is, you don't end up with hello there!. > > We define the `length' of a StatusText to be the length of the content. > This allows us to calculate offsets within the status bar without having to > strip away all the markup. > > I have a library included in Status.DZen2 (name change is coming to get > rid of the capital Z). It contains combinators and so on for marking up > StatusText using all the dzen2 commands, all from within XMonad. > Exciting! I plan to make a universal interface and a fancy interface: the > universal interface will contain all commands common to dzen2, xmobar, and > possibly taffybar. In this way, it will be possible to swap out your > statusbar without everything breaking. Maybe I'll abandon this part, but > let me know if it sounds cool to you. > > There are also facilities similar to those found in XMonad.Util.Logger for > making StatusTexts from shell commands. These are found in > Status.StatusText.Dynamic. The point of this is so that the formatting of > the information can be cleanly separated from the retrieval of the > information. This makes things more composable, and doesn't have use > relying on brittle solutions. However, you can still just plug in your > conky stuff and pipe it through xmonad if you want to just get it up and > running to see what it's like. I will be adding a few `standard' > StatusTexts in Status.System. > > I have replicated the facilities found in XMonad.Hooks.DynamicLog's PP's > by factoring out the different parts of the PP and then wrapping those in > StatusTexts in Status.X. Big ups to the creator of DynamicLog's PPs. They > are a fantastic idea within the domain of their applicability, and I used a > lot of the code from them. > > I will be spending the coming days cleaning up the codebase and getting it > ready to be submitted for possible inclusion in xmonad-contrib. I don't > think it even compiles right now, but past versions of it have worked so > I'm not super worried about there being a fundamental flaw in it or > whatever. There are some examples using battery in Status.System of > composing a StatusText to format content using the monadic interface in > Status.DZen2.Fancy. > > Finally, you take your StatusTexts, stick them in a list (one for the > left, middle, and right side of the bar respectively), and then render them > to a string. This is the part that isn't quite done yet, but it's also > probably the most straightforward. More on that later. > > Obviously, this package is best used with XMonad.Util.Timer, since you > probably want your uptime and stuff to actually update properly with time, > and not just on X events. > > [License] > > Its currently GPLv3, but I have no qualms about changing it once its ready. > > [Conclusion] > > I'd love to hear some feedback on this. Does anyone even care? Maybe > this is better left as just a personal package for myself. I have no > idea. I just felt it solved a rather general problem, and so could > possibly be of use to other people. If it helps reduce the (in my opinion) > ugly hacky use of Conky and 2+ dzen bars, then I think that's pretty good. > Let me know! > > Sincerely, > Matt > _______________________________________________ > 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 Dec 18 17:17:44 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Fri, 18 Dec 2015 12:17:44 -0500 Subject: [xmonad] Migrate from String to Data.Text [proposal] In-Reply-To: References: Message-ID: On Fri, Dec 18, 2015 at 12:12 PM, Matt Walker wrote: > The long and the short of it is that [Char] is a suboptimal choice to use > for anything except possibly short identifiers Almost all uses of String in xmonad are very short; if not, you're likely doing something wrong. (The exception is the help text which does not need to be optimal, and is simply output as is in what amounts to the most optimal use case for lists. Meanwhile the overhead of Text is significant for very short strings such as xmonad uses. Use of Text in this case is a pessimization. It would be on you to demonstrate that switching to Text is a net gain. -- 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 gwern at gwern.net Fri Dec 18 17:18:21 2015 From: gwern at gwern.net (Gwern Branwen) Date: Fri, 18 Dec 2015 12:18:21 -0500 Subject: [xmonad] Migrate from String to Data.Text [proposal] In-Reply-To: References: Message-ID: On Fri, Dec 18, 2015 at 12:12 PM, Matt Walker wrote: > The LANGUAGE pragma of OverloadedStrings allows you to use String literals > as Text literals, so that wouldn't be the main problem. The main issue is > changing all the interfaces so they accept Text instead of String, and how > this would impact existing user configs, and the xmonad-contrib archive. > Every time you use ++ you would have to replace it with <>, the Monoid infix > mappend operator. I doubt many people use : to build Strings, but in those > instances those would have to be changed too. Finally, pattern matching on > Strings like (x:xs) would break as well. All other functions would require > changing from their String/List counterpart to the Text one. Since the > names clash, one would have to import qualified as, for instance, T and call > T.intersperse or whatever. It would be a non-trivial undertaking, but > certainly doable. I don't see a single benefit for the users to undergo this invasive and painful upgrade, which is particularly harsh on the less experienced Haskellers as it involves subtleties of types and an unfamiliar Text type. Neither of your two listed benefits is at all relevant to users: Xmonad and all its extensions are not doing more than trivial amounts of string manipulation, and Xmonad as a whole is not even a performance bottleneck - X and the windows being displayed are the usual slow parts. -- gwern http://www.gwern.net From byorgey at gmail.com Fri Dec 18 17:39:34 2015 From: byorgey at gmail.com (Brent Yorgey) Date: Fri, 18 Dec 2015 17:39:34 +0000 Subject: [xmonad] Migrate from String to Data.Text [proposal] In-Reply-To: References: Message-ID: I would also note that it's not as if xmonad developers are unaware of the existence of Text. The fact is that the first version of xmonad was released two years prior to the first release of text (2007 vs 2009). So at the time there was simply no alternative to String. By the time text became stable and widely accepted, xmonad-contrib was already quite large. I think converting all of xmonad-contrib from String to Text would be a much larger and more tedious undertaking than you seem to think. Even if someone put in the effort to do that, it would indeed break pretty much every user config ever, for little benefit. By and large, xmonad users (some of whom do not even know very much Haskell) have come to expect extreme stability from xmonad. (I have been running essentially the same config unchanged for many, many years.) Forcing a bunch of people with little Haskell experience to upgrade their configs from String to Data.Text would probably result in many of them abandoning xmonad. Personally, I definitely prefer doing the Right Thing over preserving backwards compatibility (witness how many breaking changes we routinely introduce with each new release of the diagrams library). But I just don't think this makes sense for xmonad. -Brent On Fri, Dec 18, 2015 at 11:12 AM Matt Walker wrote: > Hi everyone, > > I noticed that xmonad and xmonad-contrib both prefer to use of String = > [Char] for their stringy data-types. This is probably a terrible idea. I > cite some sources here, then outline their arguments below. > > http://www.alexeyshmalko.com/2015/haskell-string-types/ > https://mail.haskell.org/pipermail/haskell-cafe/2014-June/114745.html > > __String is Bad__ > > 1) Char is a horribly inefficient representation of a character, being an > entire machine word in length (at least 32 bits). Actually, it's worse: > each Char takes up _two_ machine words in GHC, since it needs one to store > GC information in. See the slide in the first link for more details. > Data.Text stores the characters in compact arrays. > > 2) Lists are lazy, which makes their evaluation slower. You have to thunk > on each character, which is pretty silly most of the time. Normally you > want to read in at least _chunks_ of string all at once. Data.Text is > strict, but Data.Text.Lazy exists and is (as you would assume) lazy when > you need it. > > The long and the short of it is that [Char] is a suboptimal choice to use > for anything except possibly short identifiers; Haskell (via GHC) is a > compiled language, and yet performs orders of magnitudes worse than even > Perl and Python on text processing when using Data.String. There is simply > no good reason to use String when Text exists. > > __Alternatives__ > > The other alternative is ByteString. Although ByteString is a great type > for binary data, and specifically for data exchange protocols, it seems > that it would inappropriate in this situation, due to the replacement of > most (if not all) instances being actual textual data, which obviously Text > is optimized for. > > __Migration Issues__ > > Assuming we can agree that Text > String then, the main problem to > switching would be the pain of migration, and whether this would be worth > it. I argue it wouldn't be so bad, and is worth doing on principle alone. > > The LANGUAGE pragma of OverloadedStrings allows you to use String literals > as Text literals, so that wouldn't be the main problem. The main issue is > changing all the interfaces so they accept Text instead of String, and how > this would impact existing user configs, and the xmonad-contrib archive. > Every time you use ++ you would have to replace it with <>, the Monoid > infix mappend operator. I doubt many people use : to build Strings, but in > those instances those would have to be changed too. Finally, pattern > matching on Strings like (x:xs) would break as well. All other functions > would require changing from their String/List counterpart to the Text one. > Since the names clash, one would have to import qualified as, for instance, > T and call T.intersperse or whatever. It would be a non-trivial > undertaking, but certainly doable. > > __Other Breaking Changes__ > > Are there other niggling issues that exist in the codebase that would > cause breaking changes? Perhaps it would be a good idea to get a list of > them all and see if it's worth breaking backwards compatibility to fix them > all at once? I'm a purist when it comes to code, but I would like to hear > what other people think, and just how angry they would be with this > change. I have no idea as to what xmonad and xmonad-contrib's breaking > changes policy is. > > Obviously I'm not proposing this change be undertaken for 0.13 -- I was > aiming for more 0.14 or later. > > Let me know what you think. > > Sincerely, > Matt > _______________________________________________ > 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 Fri Dec 18 20:52:43 2015 From: byorgey at gmail.com (Brent Yorgey) Date: Fri, 18 Dec 2015 20:52:43 +0000 Subject: [xmonad] Code Freeze for v0.12 and Time to Test! In-Reply-To: References: <87eges6dnq.fsf@pmade.com> <87oadt3tit.fsf@pmade.com> Message-ID: Sorry it took a little longer to get to this than I thought, I had a few unexpected things to deal with at the end of the semester. But I think everything looks good now and I'm about to pull the trigger and upload to Hackage, unless anyone has any last minute questions/comments. On Mon, Dec 14, 2015 at 2:06 PM Tuncer Ayaz wrote: > On 14 December 2015 at 17:05, Peter Jones wrote: > > If someone can explicitly state that all the xmonad + xmonad-contrib > > tests pass under 7.10.3 then I'm happy to add it to the tested compilers > > list in the cabal file. > > I didn't run tests, but fwiw I'm using xmonad + xmonad-contrib built > with 7.10.3. > _______________________________________________ > 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 Fri Dec 18 20:59:15 2015 From: byorgey at gmail.com (Brent Yorgey) Date: Fri, 18 Dec 2015 20:59:15 +0000 Subject: [xmonad] Code Freeze for v0.12 and Time to Test! In-Reply-To: References: <87eges6dnq.fsf@pmade.com> <87oadt3tit.fsf@pmade.com> Message-ID: OK, well, I've tested everything and put v0.12 tags on both xmonad and xmonad-contrib. However, it appears that only Adam Vogt has the power to upload these packages to Hackage. Adam, could you add me and Peter as uploaders/maintainers for those packages on Hackage? Thanks! -Brent On Fri, Dec 18, 2015 at 2:52 PM Brent Yorgey wrote: > Sorry it took a little longer to get to this than I thought, I had a few > unexpected things to deal with at the end of the semester. But I think > everything looks good now and I'm about to pull the trigger and upload to > Hackage, unless anyone has any last minute questions/comments. > > On Mon, Dec 14, 2015 at 2:06 PM Tuncer Ayaz wrote: > >> On 14 December 2015 at 17:05, Peter Jones wrote: >> > If someone can explicitly state that all the xmonad + xmonad-contrib >> > tests pass under 7.10.3 then I'm happy to add it to the tested compilers >> > list in the cabal file. >> >> I didn't run tests, but fwiw I'm using xmonad + xmonad-contrib built >> with 7.10.3. >> _______________________________________________ >> 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 Dec 18 21:18:51 2015 From: vogt.adam at gmail.com (adam vogt) Date: Fri, 18 Dec 2015 16:18:51 -0500 Subject: [xmonad] Code Freeze for v0.12 and Time to Test! In-Reply-To: References: <87eges6dnq.fsf@pmade.com> <87oadt3tit.fsf@pmade.com> Message-ID: Hello Brent and Peter, Hackage should accept your upload now. Thanks for putting this release together Regards Adam On Dec 18, 2015 3:59 PM, "Brent Yorgey" wrote: > OK, well, I've tested everything and put v0.12 tags on both xmonad and > xmonad-contrib. However, it appears that only Adam Vogt has the power to > upload these packages to Hackage. Adam, could you add me and Peter as > uploaders/maintainers for those packages on Hackage? Thanks! > > -Brent > > On Fri, Dec 18, 2015 at 2:52 PM Brent Yorgey wrote: > >> Sorry it took a little longer to get to this than I thought, I had a few >> unexpected things to deal with at the end of the semester. But I think >> everything looks good now and I'm about to pull the trigger and upload to >> Hackage, unless anyone has any last minute questions/comments. >> >> On Mon, Dec 14, 2015 at 2:06 PM Tuncer Ayaz >> wrote: >> >>> On 14 December 2015 at 17:05, Peter Jones wrote: >>> > If someone can explicitly state that all the xmonad + xmonad-contrib >>> > tests pass under 7.10.3 then I'm happy to add it to the tested >>> compilers >>> > list in the cabal file. >>> >>> I didn't run tests, but fwiw I'm using xmonad + xmonad-contrib built >>> with 7.10.3. >>> _______________________________________________ >>> 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 Mon Dec 21 19:15:43 2015 From: byorgey at gmail.com (Brent Yorgey) Date: Mon, 21 Dec 2015 19:15:43 +0000 Subject: [xmonad] Code Freeze for v0.12 and Time to Test! In-Reply-To: References: <87eges6dnq.fsf@pmade.com> <87oadt3tit.fsf@pmade.com> Message-ID: Thanks Adam! xmonad 0.12 is now on Hackage! On Fri, Dec 18, 2015 at 3:18 PM adam vogt wrote: > Hello Brent and Peter, > > Hackage should accept your upload now. > > Thanks for putting this release together > > Regards > > > Adam > On Dec 18, 2015 3:59 PM, "Brent Yorgey" wrote: > >> OK, well, I've tested everything and put v0.12 tags on both xmonad and >> xmonad-contrib. However, it appears that only Adam Vogt has the power to >> upload these packages to Hackage. Adam, could you add me and Peter as >> uploaders/maintainers for those packages on Hackage? Thanks! >> >> -Brent >> >> On Fri, Dec 18, 2015 at 2:52 PM Brent Yorgey wrote: >> >>> Sorry it took a little longer to get to this than I thought, I had a few >>> unexpected things to deal with at the end of the semester. But I think >>> everything looks good now and I'm about to pull the trigger and upload to >>> Hackage, unless anyone has any last minute questions/comments. >>> >>> On Mon, Dec 14, 2015 at 2:06 PM Tuncer Ayaz >>> wrote: >>> >>>> On 14 December 2015 at 17:05, Peter Jones wrote: >>>> > If someone can explicitly state that all the xmonad + xmonad-contrib >>>> > tests pass under 7.10.3 then I'm happy to add it to the tested >>>> compilers >>>> > list in the cabal file. >>>> >>>> I didn't run tests, but fwiw I'm using xmonad + xmonad-contrib built >>>> with 7.10.3. >>>> _______________________________________________ >>>> 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 Mon Dec 21 19:16:14 2015 From: byorgey at gmail.com (Brent Yorgey) Date: Mon, 21 Dec 2015 19:16:14 +0000 Subject: [xmonad] Code Freeze for v0.12 and Time to Test! In-Reply-To: References: <87eges6dnq.fsf@pmade.com> <87oadt3tit.fsf@pmade.com> Message-ID: Is there anything else that needs to happen? e.g. does the website need to be updated? On Mon, Dec 21, 2015 at 1:15 PM Brent Yorgey wrote: > Thanks Adam! xmonad 0.12 is now on Hackage! > > On Fri, Dec 18, 2015 at 3:18 PM adam vogt wrote: > >> Hello Brent and Peter, >> >> Hackage should accept your upload now. >> >> Thanks for putting this release together >> >> Regards >> >> >> Adam >> On Dec 18, 2015 3:59 PM, "Brent Yorgey" wrote: >> >>> OK, well, I've tested everything and put v0.12 tags on both xmonad and >>> xmonad-contrib. However, it appears that only Adam Vogt has the power to >>> upload these packages to Hackage. Adam, could you add me and Peter as >>> uploaders/maintainers for those packages on Hackage? Thanks! >>> >>> -Brent >>> >>> On Fri, Dec 18, 2015 at 2:52 PM Brent Yorgey wrote: >>> >>>> Sorry it took a little longer to get to this than I thought, I had a >>>> few unexpected things to deal with at the end of the semester. But I think >>>> everything looks good now and I'm about to pull the trigger and upload to >>>> Hackage, unless anyone has any last minute questions/comments. >>>> >>>> On Mon, Dec 14, 2015 at 2:06 PM Tuncer Ayaz >>>> wrote: >>>> >>>>> On 14 December 2015 at 17:05, Peter Jones wrote: >>>>> > If someone can explicitly state that all the xmonad + xmonad-contrib >>>>> > tests pass under 7.10.3 then I'm happy to add it to the tested >>>>> compilers >>>>> > list in the cabal file. >>>>> >>>>> I didn't run tests, but fwiw I'm using xmonad + xmonad-contrib built >>>>> with 7.10.3. >>>>> _______________________________________________ >>>>> 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 mlists at pmade.com Mon Dec 21 21:08:08 2015 From: mlists at pmade.com (Peter Jones) Date: Mon, 21 Dec 2015 14:08:08 -0700 Subject: [xmonad] Code Freeze for v0.12 and Time to Test! References: <87eges6dnq.fsf@pmade.com> <87oadt3tit.fsf@pmade.com> Message-ID: <87lh8nwlvr.fsf@pmade.com> Brent Yorgey writes: > Is there anything else that needs to happen? e.g. does the website need to > be updated? According to the TODO file this is what we have left: * generate, and push website haddocks with xmonad-web/gen-docs.sh * update #xmonad topic * email announce -- Peter Jones, Founder, Devalot.com Defending the honor of good code From tuncer.ayaz at gmail.com Tue Dec 22 10:13:50 2015 From: tuncer.ayaz at gmail.com (Tuncer Ayaz) Date: Tue, 22 Dec 2015 11:13:50 +0100 Subject: [xmonad] Code Freeze for v0.12 and Time to Test! In-Reply-To: <87lh8nwlvr.fsf@pmade.com> References: <87eges6dnq.fsf@pmade.com> <87oadt3tit.fsf@pmade.com> <87lh8nwlvr.fsf@pmade.com> Message-ID: On 21 December 2015 at 22:08, Peter Jones wrote: > Brent Yorgey writes: > > Is there anything else that needs to happen? e.g. does the website > > need to be updated? > > According to the TODO file this is what we have left: > > * generate, and push website haddocks with xmonad-web/gen-docs.sh > > * update #xmonad topic > > * email announce Maybe the announcement should end with a list of contributors. We can begin with the git repos, and for the next release it might make sense to include tickets as well, but I'm not sure about that. You could run something like this on all repos and embed a single sorted list: git log v0.11.. --format="%aN" --reverse \ | perl -e 'my %dedupe; while () { print unless $dedupe{$_}++}' From matt.g.d.walker at gmail.com Tue Dec 22 14:01:26 2015 From: matt.g.d.walker at gmail.com (Matt Walker) Date: Tue, 22 Dec 2015 09:01:26 -0500 Subject: [xmonad] Migrate from String to Data.Text [proposal] In-Reply-To: References: Message-ID: Hey there! Having thought it over after listening to what you've said, you're all probably right. It's just not worth breaking backwards compatibility for, and I didn't properly consider the difficulties faced by people who are unfamiliar with GHC and Haskell in general. It's kind of a shame that OverloadedStrings can't be coerced into some sort of DWIM mode, where it converts to and from strings within existing code where needed. I've fallen into the hell of dealing with String, [Word8], ByteString, and Text all within the same program before; it's not fun. It's amazing that xmonad is almost 10 years old now! I will focus my efforts on extending xmonad in the way I'd like, and not worry so much about String. If there is a point where I need to do lots of string processing within xmonad I can revisit this. Thanks again for the insight. Sincerely, Matt On Dec 18, 2015 12:39 PM, "Brent Yorgey" wrote: > I would also note that it's not as if xmonad developers are unaware of the > existence of Text. The fact is that the first version of xmonad was > released two years prior to the first release of text (2007 vs 2009). So > at the time there was simply no alternative to String. By the time text > became stable and widely accepted, xmonad-contrib was already quite large. > > I think converting all of xmonad-contrib from String to Text would be a > much larger and more tedious undertaking than you seem to think. Even if > someone put in the effort to do that, it would indeed break pretty much > every user config ever, for little benefit. By and large, xmonad users > (some of whom do not even know very much Haskell) have come to expect > extreme stability from xmonad. (I have been running essentially the same > config unchanged for many, many years.) Forcing a bunch of people with > little Haskell experience to upgrade their configs from String to Data.Text > would probably result in many of them abandoning xmonad. > > Personally, I definitely prefer doing the Right Thing over preserving > backwards compatibility (witness how many breaking changes we routinely > introduce with each new release of the diagrams library). But I just don't > think this makes sense for xmonad. > > -Brent > > On Fri, Dec 18, 2015 at 11:12 AM Matt Walker > wrote: > >> Hi everyone, >> >> I noticed that xmonad and xmonad-contrib both prefer to use of String = >> [Char] for their stringy data-types. This is probably a terrible idea. I >> cite some sources here, then outline their arguments below. >> >> http://www.alexeyshmalko.com/2015/haskell-string-types/ >> https://mail.haskell.org/pipermail/haskell-cafe/2014-June/114745.html >> >> __String is Bad__ >> >> 1) Char is a horribly inefficient representation of a character, being an >> entire machine word in length (at least 32 bits). Actually, it's worse: >> each Char takes up _two_ machine words in GHC, since it needs one to store >> GC information in. See the slide in the first link for more details. >> Data.Text stores the characters in compact arrays. >> >> 2) Lists are lazy, which makes their evaluation slower. You have to >> thunk on each character, which is pretty silly most of the time. Normally >> you want to read in at least _chunks_ of string all at once. Data.Text is >> strict, but Data.Text.Lazy exists and is (as you would assume) lazy when >> you need it. >> >> The long and the short of it is that [Char] is a suboptimal choice to use >> for anything except possibly short identifiers; Haskell (via GHC) is a >> compiled language, and yet performs orders of magnitudes worse than even >> Perl and Python on text processing when using Data.String. There is simply >> no good reason to use String when Text exists. >> >> __Alternatives__ >> >> The other alternative is ByteString. Although ByteString is a great type >> for binary data, and specifically for data exchange protocols, it seems >> that it would inappropriate in this situation, due to the replacement of >> most (if not all) instances being actual textual data, which obviously Text >> is optimized for. >> >> __Migration Issues__ >> >> Assuming we can agree that Text > String then, the main problem to >> switching would be the pain of migration, and whether this would be worth >> it. I argue it wouldn't be so bad, and is worth doing on principle alone. >> >> The LANGUAGE pragma of OverloadedStrings allows you to use String >> literals as Text literals, so that wouldn't be the main problem. The main >> issue is changing all the interfaces so they accept Text instead of String, >> and how this would impact existing user configs, and the xmonad-contrib >> archive. Every time you use ++ you would have to replace it with <>, the >> Monoid infix mappend operator. I doubt many people use : to build Strings, >> but in those instances those would have to be changed too. Finally, >> pattern matching on Strings like (x:xs) would break as well. All other >> functions would require changing from their String/List counterpart to the >> Text one. Since the names clash, one would have to import qualified as, >> for instance, T and call T.intersperse or whatever. It would be a >> non-trivial undertaking, but certainly doable. >> >> __Other Breaking Changes__ >> >> Are there other niggling issues that exist in the codebase that would >> cause breaking changes? Perhaps it would be a good idea to get a list of >> them all and see if it's worth breaking backwards compatibility to fix them >> all at once? I'm a purist when it comes to code, but I would like to hear >> what other people think, and just how angry they would be with this >> change. I have no idea as to what xmonad and xmonad-contrib's breaking >> changes policy is. >> >> Obviously I'm not proposing this change be undertaken for 0.13 -- I was >> aiming for more 0.14 or later. >> >> Let me know what you think. >> >> Sincerely, >> Matt >> _______________________________________________ >> 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 Tue Dec 22 14:06:04 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 22 Dec 2015 09:06:04 -0500 Subject: [xmonad] Migrate from String to Data.Text [proposal] In-Reply-To: References: Message-ID: On Tue, Dec 22, 2015 at 9:01 AM, Matt Walker wrote: > I will focus my efforts on extending xmonad in the way I'd like, and not > worry so much about String. If there is a point where I need to do lots of > string processing within xmonad I can revisit this. In general, if you find yourself dealing with sufficiently large strings to justify Text, it probably doesn't belong in the window manager. You really want it to be small and fast and do as much as possible outside the WM; otherwise yoy'll find opening / moving / etc. windows to be sluggish at best and possibly even cause hangs because the WM is doing something else instead of responding to window requests. -- 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 Dec 22 18:00:40 2015 From: vogt.adam at gmail.com (adam vogt) Date: Tue, 22 Dec 2015 13:00:40 -0500 Subject: [xmonad] Code Freeze for v0.12 and Time to Test! In-Reply-To: References: <87eges6dnq.fsf@pmade.com> <87oadt3tit.fsf@pmade.com> <87lh8nwlvr.fsf@pmade.com> Message-ID: On Dec 22, 2015 5:14 AM, "Tuncer Ayaz" wrote: > > On 21 December 2015 at 22:08, Peter Jones wrote: > > Brent Yorgey writes: > > > Is there anything else that needs to happen? e.g. does the website > > > need to be updated? > > > > According to the TODO file this is what we have left: > > > > * generate, and push website haddocks with xmonad-web/gen-docs.sh > > > > * update #xmonad topic > > > > * email announce > > Maybe the announcement should end with a list of contributors. We can > begin with the git repos, and for the next release it might make sense > to include tickets as well, but I'm not sure about that. You could run > something like this on all repos and embed a single sorted list: > > git log v0.11.. --format="%aN" --reverse \ > | perl -e 'my %dedupe; while () { print unless $dedupe{$_}++}' We did list contributors in previous announces. Darcs cleaned up the list using an .authorspellings file (checked into the contrib repo), but I can't find an equivalent feature built-into git. Regards, Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Tue Dec 22 18:02:32 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 22 Dec 2015 13:02:32 -0500 Subject: [xmonad] Code Freeze for v0.12 and Time to Test! In-Reply-To: References: <87eges6dnq.fsf@pmade.com> <87oadt3tit.fsf@pmade.com> <87lh8nwlvr.fsf@pmade.com> Message-ID: On Tue, Dec 22, 2015 at 1:00 PM, adam vogt wrote: > We did list contributors in previous announces. Darcs cleaned up the list > using an .authorspellings file (checked into the contrib repo), but I can't > find an equivalent feature built-into git. Git can use .mailmap but IIRC it's not as automated. -- 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 bogdan.sinitsyn at gmail.com Tue Dec 22 19:21:59 2015 From: bogdan.sinitsyn at gmail.com (Bogdan Sinitsyn) Date: Tue, 22 Dec 2015 22:21:59 +0300 Subject: [xmonad] More possibilities for border width customization Message-ID: <45339524.5RmUFrcah5@navi> Sometimes it would be better to customize border width depending on window. Is it possible to merge this functionality into core? -- Bogdan Sinitsyn From vogt.adam at gmail.com Tue Dec 22 21:43:21 2015 From: vogt.adam at gmail.com (adam vogt) Date: Tue, 22 Dec 2015 16:43:21 -0500 Subject: [xmonad] Code Freeze for v0.12 and Time to Test! In-Reply-To: References: <87eges6dnq.fsf@pmade.com> <87oadt3tit.fsf@pmade.com> <87lh8nwlvr.fsf@pmade.com> Message-ID: I've converted the .authorspellings to a .mailmap. On Tue, Dec 22, 2015 at 1:02 PM, Brandon Allbery wrote: > On Tue, Dec 22, 2015 at 1:00 PM, adam vogt wrote: > >> We did list contributors in previous announces. Darcs cleaned up the list >> using an .authorspellings file (checked into the contrib repo), but I can't >> find an equivalent feature built-into git. > > > Git can use .mailmap but IIRC it's not as automated. > > -- > 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 tuncer.ayaz at gmail.com Mon Dec 28 13:51:20 2015 From: tuncer.ayaz at gmail.com (Tuncer Ayaz) Date: Mon, 28 Dec 2015 14:51:20 +0100 Subject: [xmonad] Code Freeze for v0.12 and Time to Test! In-Reply-To: References: <87eges6dnq.fsf@pmade.com> <87oadt3tit.fsf@pmade.com> Message-ID: On 21 December 2015 at 20:16, Brent Yorgey wrote: > Is there anything else that needs to happen? e.g. does the website > need to be updated? Here's a minimal, modern xmonad.hs, which we should include in the announcement and ideally also on the website's getting started page. Feel free to improve. import System.Exit import XMonad import XMonad.Hooks.DynamicLog import XMonad.Hooks.ManageDocks import XMonad.Hooks.ManageHelpers import XMonad.Layout.Fullscreen import XMonad.Layout.LayoutHints import XMonad.Layout.NoBorders import XMonad.Prompt import XMonad.Prompt.ConfirmPrompt import XMonad.Prompt.Shell import XMonad.Util.EZConfig import XMonad.Util.Run(hPutStrLn, spawnPipe) main = do xmproc <- spawnPipe "xmobar ~/.xmonad/xmobarrc" xmonad $ defaultConfig { terminal = "xterm" , manageHook = myManageHook <+> fullscreenManageHook <+> manageDocks <+> manageHook defaultConfig , layoutHook = fullscreenFloat $ fullscreenFocus $ layoutHints $ smartBorders $ avoidStruts $ layoutHook defaultConfig , handleEventHook = fullscreenEventHook , logHook = dynamicLogWithPP $ xmobarPP { ppOutput = hPutStrLn xmproc } } `removeKeysP` [ "M-S-q" , "M-p" ] `additionalKeysP` [ ("M-S-q", confirmPrompt myXPConfig "exit" $ io exitSuccess) , ("M-p", shellPrompt myXPConfig) ] `additionalKeys` [ ((mod4Mask, xK_q), spawn "xmonad --recompile && xmonad --restart") ] myXPConfig = defaultXPConfig { position = Top , promptBorderWidth = 0 , defaultText = "" , alwaysHighlight = True , font = "9x15" } myManageHook = composeAll [ className =? "Pidgin" --> doFloat , className =? "MuPDF" --> doFloat , className =? "XCalc" --> doFloat , className =? "mpv" --> doFloat ] -------------- next part -------------- A non-text attachment was scrubbed... Name: sample-xmonad.hs Type: application/octet-stream Size: 1865 bytes Desc: not available URL: From tuncer.ayaz at gmail.com Mon Dec 28 13:55:31 2015 From: tuncer.ayaz at gmail.com (Tuncer Ayaz) Date: Mon, 28 Dec 2015 14:55:31 +0100 Subject: [xmonad] Code Freeze for v0.12 and Time to Test! In-Reply-To: References: <87eges6dnq.fsf@pmade.com> <87oadt3tit.fsf@pmade.com> Message-ID: On 28 December 2015 at 14:51, Tuncer Ayaz wrote: > Here's a minimal, modern xmonad.hs, which we should include in the > announcement and ideally also on the website's getting started page. > Feel free to improve. Accidentally omitted: What's modern about it is that it uses (1) the new config module (2) built-in launcher prompt (3) built-in prompt module for exit confirmation It doesn't require dmenu and shows how to configure key bindings the modern way. From alainbe at free.fr Mon Dec 28 16:53:34 2015 From: alainbe at free.fr (Alain Bertrand) Date: Mon, 28 Dec 2015 17:53:34 +0100 Subject: [xmonad] Code Freeze for v0.12 and Time to Test! In-Reply-To: References: <87eges6dnq.fsf@pmade.com> <87oadt3tit.fsf@pmade.com> Message-ID: <5681690E.5050803@free.fr> Le 28/12/2015 14:51, Tuncer Ayaz a ?crit : > Here's a minimal, modern xmonad.hs, which we should include in the > announcement and ideally also on the website's getting started page. > Feel free to improve. > > import System.Exit [snip quote] Hi, all, May I had a suggestion : add as a comment what is needed to use xmonad with AZERTY keyboards, where defaults for 1234567890 are &?"'(-?_?? . Ideally, one should have only to uncomment a few line to get xmonad to work whith those keyboards. Best regards, Alain (add sorry for the personal answer instead of the mailing-list) From devin.mullins at gmail.com Mon Dec 28 18:30:40 2015 From: devin.mullins at gmail.com (Devin Mullins) Date: Mon, 28 Dec 2015 10:30:40 -0800 Subject: [xmonad] Code Freeze for v0.12 and Time to Test! In-Reply-To: References: <87eges6dnq.fsf@pmade.com> <87oadt3tit.fsf@pmade.com> Message-ID: Interesting, I didn't know about ConfirmPrompt! So many contrib modules. FYI, you don't need to use removeKeysP to update existing key bindings, as it's backed by a Data.Map - just the additionalKeysP will do. Also, insert shameless plug for the even more modern X.C.Prime module - I think it makes configs look nicer, personally. On Dec 28, 2015 7:56 AM, "Tuncer Ayaz" wrote: > On 28 December 2015 at 14:51, Tuncer Ayaz wrote: > > > Here's a minimal, modern xmonad.hs, which we should include in the > > announcement and ideally also on the website's getting started page. > > Feel free to improve. > > Accidentally omitted: > > What's modern about it is that it uses > > (1) the new config module > (2) built-in launcher prompt > (3) built-in prompt module for exit confirmation > > It doesn't require dmenu and shows how to configure key bindings the > modern way. > _______________________________________________ > 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 devin.mullins at gmail.com Mon Dec 28 18:32:13 2015 From: devin.mullins at gmail.com (Devin Mullins) Date: Mon, 28 Dec 2015 10:32:13 -0800 Subject: [xmonad] Code Freeze for v0.12 and Time to Test! In-Reply-To: <5681690E.5050803@free.fr> References: <87eges6dnq.fsf@pmade.com> <87oadt3tit.fsf@pmade.com> <5681690E.5050803@free.fr> Message-ID: The first result for https://www.google.com/search?q=xmonad+azerty looks good. Does that work? On Dec 28, 2015 10:53 AM, "Alain Bertrand" wrote: > Le 28/12/2015 14:51, Tuncer Ayaz a ?crit : > > > Here's a minimal, modern xmonad.hs, which we should include in the > > announcement and ideally also on the website's getting started page. > > Feel free to improve. > > > > import System.Exit > > [snip quote] > > Hi, all, > May I had a suggestion : add as a comment what is needed to use xmonad > with AZERTY keyboards, where defaults for 1234567890 are &?"'(-?_?? . > Ideally, one should have only to uncomment a few line to get xmonad to > work whith those keyboards. > > Best regards, > > Alain > > (add sorry for the personal answer instead of the mailing-list) > _______________________________________________ > 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 alainbe at free.fr Mon Dec 28 19:56:24 2015 From: alainbe at free.fr (Alain Bertrand) Date: Mon, 28 Dec 2015 20:56:24 +0100 Subject: [xmonad] Code Freeze for v0.12 and Time to Test! In-Reply-To: References: <87eges6dnq.fsf@pmade.com> <87oadt3tit.fsf@pmade.com> <5681690E.5050803@free.fr> Message-ID: <568193E8.70300@free.fr> Le 28/12/2015 19:32, Devin Mullins a ?crit : > > The first result for https://www.google.com/search?q=xmonad+azerty > looks good. Does that work? > Yes, it does, but this is not what I am hoping for. When I first tried xmonad, I encountered the link you pointed and used it but unfortunately, each time I tried to add another customization to my config file, it failed because for a non haskell-initiated user, it is *cryptic*. So I registered to this mailing list, got the help needed and can enjoy the power of xmonad but one shouldn't have to register to a mailing list to get xmonad working. The file Tuncer Ayaz has proposed contains several interesting customizations. To be fully useful, it should be very easy to use in most default keyboards on earth. Best regards, Alain > On Dec 28, 2015 10:53 AM, "Alain Bertrand" > wrote: > > Le 28/12/2015 14:51, Tuncer Ayaz a ?crit : > > > Here's a minimal, modern xmonad.hs, which we should include in the > > announcement and ideally also on the website's getting started page. > > Feel free to improve. > > > > import System.Exit > > [snip quote] > > Hi, all, > May I had a suggestion : add as a comment what is needed to use xmonad > with AZERTY keyboards, where defaults for 1234567890 are &?"'(-?_?? . > Ideally, one should have only to uncomment a few line to get xmonad to > work whith those keyboards. > > Best regards, > > Alain > > (add sorry for the personal answer instead of the mailing-list) > _______________________________________________ > xmonad mailing list > xmonad at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad > From tuncer.ayaz at gmail.com Mon Dec 28 21:29:32 2015 From: tuncer.ayaz at gmail.com (Tuncer Ayaz) Date: Mon, 28 Dec 2015 22:29:32 +0100 Subject: [xmonad] Code Freeze for v0.12 and Time to Test! In-Reply-To: References: <87eges6dnq.fsf@pmade.com> <87oadt3tit.fsf@pmade.com> Message-ID: Here's an updated post with a short text that you might want to include in the announcement: xmonad (and xmonad-contrib) have evolved a lot since its first release, and therefore it's a good idea to showcase a modern xmonad.hs. The config below will give you a good starter xmonad setup with minor customizations. These are: (1) Ask for confirmation before exiting (2) Replace default launcher binding with built-in shellPrompt, which is friendlier to use and does not require dmenu. Arguably, these customizations should be the default, but as it requires xmonad-contrib, we can not really make it the default. Some of the things you might want to do next: * customize looks * control volume and display backlight * customize layouts * customize mouse behavior * whatever you need and can imagine Save this as ~/.xmonad/xmonad.hs: import System.Exit import XMonad import XMonad.Hooks.DynamicLog import XMonad.Hooks.ManageDocks import XMonad.Hooks.ManageHelpers import XMonad.Layout.Fullscreen import XMonad.Layout.LayoutHints import XMonad.Layout.NoBorders import XMonad.Prompt import XMonad.Prompt.ConfirmPrompt import XMonad.Prompt.Shell import XMonad.Util.EZConfig import XMonad.Util.Run(hPutStrLn, spawnPipe) main = do xmproc <- spawnPipe "xmobar ~/.xmonad/xmobarrc" xmonad $ defaultConfig { terminal = "xterm" , manageHook = myManageHook <+> fullscreenManageHook <+> manageDocks <+> manageHook defaultConfig , layoutHook = fullscreenFloat $ fullscreenFocus $ layoutHints $ smartBorders $ avoidStruts $ layoutHook defaultConfig , handleEventHook = fullscreenEventHook , logHook = dynamicLogWithPP $ xmobarPP { ppOutput = hPutStrLn xmproc } } `additionalKeysP` [ -- Ask for confirmation before exiting by replacing the default -- binding with a custom one. ("M-S-q", confirmPrompt myXPConfig "exit" $ io exitSuccess) -- Replace M-p launcher binding with built-in shellPrompt, which -- is friendlier and does not require dmenu. , ("M-p", shellPrompt myXPConfig) ] `additionalKeys` [ ((mod4Mask, xK_q), spawn "xmonad --recompile && xmonad --restart") ] -- see http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Prompt.html#t:XPConfig myXPConfig = defaultXPConfig { position = Top , promptBorderWidth = 0 , defaultText = "" , alwaysHighlight = True , font = "9x15" } -- see http://xmonad.org/xmonad-docs/xmonad/XMonad-ManageHook.html myManageHook = composeAll [ className =? "Pidgin" --> doFloat , className =? "MuPDF" --> doFloat , className =? "llpp" --> doFloat , className =? "XCalc" --> doFloat , className =? "mpv" --> doFloat , className =? "Gimp" --> doFloat ] -------------- next part -------------- A non-text attachment was scrubbed... Name: sample-xmonad.hs Type: application/octet-stream Size: 2237 bytes Desc: not available URL: From tuncer.ayaz at gmail.com Mon Dec 28 21:44:19 2015 From: tuncer.ayaz at gmail.com (Tuncer Ayaz) Date: Mon, 28 Dec 2015 22:44:19 +0100 Subject: [xmonad] Code Freeze for v0.12 and Time to Test! In-Reply-To: References: <87eges6dnq.fsf@pmade.com> <87oadt3tit.fsf@pmade.com> Message-ID: On 28 December 2015 at 19:22, Devin Mullins wrote: > Interesting, I didn't know about ConfirmPrompt! So many contrib modules. Yeah, there are many hidden gems in the contrib namespace. > FYI, you don't need to use removeKeysP to update existing key bindings, as > it's backed by a Data.Map - just the additionalKeysP will do. Thanks, good catch. Posed an update. > Also, insert shameless plug for the even more modern X.C.Prime module - I > think it makes configs look nicer, personally. How would a modified version, making use of that, look? From tuncer.ayaz at gmail.com Mon Dec 28 21:46:38 2015 From: tuncer.ayaz at gmail.com (Tuncer Ayaz) Date: Mon, 28 Dec 2015 22:46:38 +0100 Subject: [xmonad] Code Freeze for v0.12 and Time to Test! In-Reply-To: References: <87eges6dnq.fsf@pmade.com> <87oadt3tit.fsf@pmade.com> Message-ID: On 28 December 2015 at 22:29, Tuncer Ayaz wrote: > Here's an updated post with a short text that you might want > to include in the announcement: > > xmonad (and xmonad-contrib) have evolved a lot since its first > release, and therefore it's a good idea to showcase a modern Typo fix: xmonad and xmonad-contrib have evolved a lot over the years, and therefore it's a good idea to showcase a modern > xmonad.hs. The config below will give you a good starter xmonad setup > with minor customizations. These are: [...] From tuncer.ayaz at gmail.com Tue Dec 29 11:30:39 2015 From: tuncer.ayaz at gmail.com (Tuncer Ayaz) Date: Tue, 29 Dec 2015 12:30:39 +0100 Subject: [xmonad] Code Freeze for v0.12 and Time to Test! In-Reply-To: References: <87eges6dnq.fsf@pmade.com> <87oadt3tit.fsf@pmade.com> Message-ID: I've removed leftover rules for mupdf and llpp. There's also no need for making Gimp floating, because Gimp stable version has a single-window mode, and there's no collection of windows anymore, if you enable that. One thing I've noticed with mpv (and mplayer) is that if you enter and leave fullscreen, then the video (inside window) is cropped by at least one column of pixels, and the window is not restored to its original floating position but moved right+down by one or more pixels. These two effects are probably related, but I don't see anything wrong with the config. Any idea what's wrong? Here's v3 with more fixes and better wording: xmonad and xmonad-contrib have evolved a lot over the years, and therefore it's a good idea to showcase a modern xmonad.hs. The config below will give you a good starter xmonad setup with minor customizations. These are: (1) Ask for confirmation before exiting (2) Replace default launcher binding with built-in shellPrompt, which is friendlier to use and does not require dmenu. Arguably, these customizations should be the default, but as it requires xmonad-contrib, we can not really make it the default. Things you might want to configure next: * customize looks * control volume and display back-light * customize layouts * customize mouse behavior * add more prompts (ssh, man, password, etc.) * whatever you can imagine and/or need Save this as ~/.xmonad/xmonad.hs: import System.Exit import XMonad import XMonad.Hooks.DynamicLog import XMonad.Hooks.ManageDocks import XMonad.Hooks.ManageHelpers import XMonad.Layout.Fullscreen import XMonad.Layout.LayoutHints import XMonad.Layout.NoBorders import XMonad.Prompt import XMonad.Prompt.ConfirmPrompt import XMonad.Prompt.Shell import XMonad.Util.EZConfig import XMonad.Util.Run(hPutStrLn, spawnPipe) main = do xmproc <- spawnPipe "xmobar ~/.xmonad/xmobarrc" xmonad $ defaultConfig { terminal = "xterm" , manageHook = myManageHook <+> fullscreenManageHook <+> manageDocks <+> manageHook defaultConfig , layoutHook = fullscreenFloat $ fullscreenFocus $ layoutHints $ smartBorders $ avoidStruts $ layoutHook defaultConfig , handleEventHook = fullscreenEventHook , logHook = dynamicLogWithPP $ xmobarPP { ppOutput = hPutStrLn xmproc } } `additionalKeysP` [ -- Ask for confirmation before exiting by replacing the default -- binding with a custom one. ("M-S-q", confirmPrompt myXPConfig "exit" $ io exitSuccess) -- Replace M-p launcher binding with built-in shellPrompt, which -- is friendlier and does not require dmenu. , ("M-p", shellPrompt myXPConfig) ] `additionalKeys` [ ((mod4Mask, xK_q), spawn "xmonad --recompile && xmonad --restart") ] -- see http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Prompt.html#t:XPConfig myXPConfig = defaultXPConfig { position = Top , promptBorderWidth = 0 , defaultText = "" , alwaysHighlight = True , font = "9x15" } -- see http://xmonad.org/xmonad-docs/xmonad/XMonad-ManageHook.html myManageHook = composeAll [ className =? "Pidgin" --> doFloat , className =? "XCalc" --> doFloat , className =? "mpv" --> doFloat ] -------------- next part -------------- A non-text attachment was scrubbed... Name: sample-xmonad.hs Type: application/octet-stream Size: 2081 bytes Desc: not available URL: From bogdan.sinitsyn at gmail.com Tue Dec 29 11:53:15 2015 From: bogdan.sinitsyn at gmail.com (Bogdan Sinitsyn) Date: Tue, 29 Dec 2015 14:53:15 +0300 Subject: [xmonad] Code Freeze for v0.12 and Time to Test! In-Reply-To: References: <87eges6dnq.fsf@pmade.com> Message-ID: <5905100.zN99sIxg7t@navi> On Tuesday, December 29, 2015 12:30:39 PM MSK Tuncer Ayaz wrote: > One thing I've noticed with mpv (and mplayer) is that > if you enter and leave fullscreen, then the video (inside window) is > cropped by at least one column of pixels, and the window is not > restored to its original floating position but moved right+down by one > or more pixels. These two effects are probably related, but I don't > see anything wrong with the config. Any idea what's wrong? Maybe it's because border width is reapplied by core and then by layout? -- Bogdan Sinitsyn From byorgey at gmail.com Tue Dec 29 21:10:56 2015 From: byorgey at gmail.com (Brent Yorgey) Date: Tue, 29 Dec 2015 21:10:56 +0000 Subject: [xmonad] More possibilities for border width customization In-Reply-To: <45339524.5RmUFrcah5@navi> References: <45339524.5RmUFrcah5@navi> Message-ID: This seems to me like it would be a rather invasive breaking change (changing the type of a field in the main xmonad config record). Personally I do not think it would be worth it. However if someone makes a patch, along with a reasoned justification, it will certainly be considered. -Brent On Tue, Dec 22, 2015 at 1:25 PM Bogdan Sinitsyn wrote: > Sometimes it would be better to customize border width depending on > window. Is > it possible to merge this functionality into core? > -- > Bogdan Sinitsyn > _______________________________________________ > 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 Tue Dec 29 21:19:38 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 29 Dec 2015 16:19:38 -0500 Subject: [xmonad] More possibilities for border width customization In-Reply-To: References: <45339524.5RmUFrcah5@navi> Message-ID: On Tue, Dec 29, 2015 at 4:10 PM, Brent Yorgey wrote: > This seems to me like it would be a rather invasive breaking change > (changing the type of a field in the main xmonad config record). > Personally I do not think it would be worth it. However if someone makes a > patch, along with a reasoned justification, it will certainly be considered. > Not everything belongs in core. What I usually suggest in IRC is: setBorder bw = ask >>= \w -> liftX (withDisplay $ \d -> io $ setWindowBorderWidth d w bw) >> idHook and then apply it to windows in the ManageHook. An argument could possibly be made for that function going into the core... but probably should start out in contrib. -- 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 bogdan.sinitsyn at gmail.com Wed Dec 30 04:05:17 2015 From: bogdan.sinitsyn at gmail.com (Bogdan Sinitsyn) Date: Wed, 30 Dec 2015 07:05:17 +0300 Subject: [xmonad] More possibilities for border width customization In-Reply-To: References: <45339524.5RmUFrcah5@navi> Message-ID: <2594779.zEtYM2mXV8@navi> On Tuesday, December 29, 2015 9:10:56 PM MSK Brent Yorgey wrote: > This seems to me like it would be a rather invasive breaking change > (changing the type of a field in the main xmonad config record). > Personally I do not think it would be worth it. However if someone makes a > patch, along with a reasoned justification, it will certainly be considered. > > -Brent > > On Tue, Dec 22, 2015 at 1:25 PM Bogdan Sinitsyn > > wrote: > > Sometimes it would be better to customize border width depending on > > window. Is > > it possible to merge this functionality into core? > > -- > > Bogdan Sinitsyn > > _______________________________________________ > > xmonad mailing list > > xmonad at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad It can be done by adding new field of type `Query (Maybe Dimension)`. This solution does not break compatibility with almost all old configurations(it will break only those, who use `XConfig { ... }`, not `def { ... }`). PR on GitHub is already made. -- Bogdan Sinitsyn From asjo at koldfront.dk Thu Dec 31 16:35:48 2015 From: asjo at koldfront.dk (Adam =?utf-8?Q?Sj=C3=B8gren?=) Date: Thu, 31 Dec 2015 17:35:48 +0100 Subject: [xmonad] Not running my startupHook on restart Message-ID: <87bn9660ez.fsf@tullinup.koldfront.dk> I have a startupHook that spawns a number of windows on various workspaces. When I restart XMonad, I don't want those windows opened again. Is there an easy way to have startupHook only run when logging in, and not when restarting XMonad? The way I have tried to solve this, unsuccessfully, is to make my startupHook look like this: myStartup = when (noRun /= "1") $ do spawnOn "1" "emacs" spawnOn "6" "x-terminal-emulator" -- and so on... where noRun = unsafePerformIO $ env "NO_STARTUP_HOOK" "0" env :: String -> String -> IO String env variable fallthrough = getEnv variable `Control.Exception.catch` econst fallthrough (where getEnv is imported from System.Environment). And then I have changed the restart keybinding like this: , ("M-S-r", spawn "xmonad --recompile; export NO_STARTUP_HOOK=1; xmonad --restart") Unfortunately it doesn't work - I guess something "more" is going on when "xmonad --restart" runs, because if I add a key: , ("M-S-y", spawn "export HEP=yay; notify-send --expire-time 2000 'Testing' \"ENV: [$HEP]\"") then pressing M-S-y gives me an alert with the text "ENV: [yay]" in it. But if I do: , ("M-S-y", spawn "notify-send --expire-time 2000 'Testing' \"ENV: [$NO_STARTUP_HOOK]\"") the notification says "ENV: []" regardless of whether I have restarted XMonad or not. I have a feeling that I am taking the long walk to solve this - any ideas of the easy way to the goal here? Thanks! Adam -- "H?r kommer r?dslan, nu igen Adam Sj?gren N?r alla fj?rilar i magen n?las upp asjo at koldfront.dk till ett m?nster p? min s?ng" From allbery.b at gmail.com Thu Dec 31 16:42:34 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Thu, 31 Dec 2015 11:42:34 -0500 Subject: [xmonad] Not running my startupHook on restart In-Reply-To: <87bn9660ez.fsf@tullinup.koldfront.dk> References: <87bn9660ez.fsf@tullinup.koldfront.dk> Message-ID: On Thu, Dec 31, 2015 at 11:35 AM, Adam Sj?gren wrote: > I have a startupHook that spawns a number of windows on various > workspaces. > > When I restart XMonad, I don't want those windows opened again. > > Use XMonad.Util.SpawnOnce.spawnOnce. If you want to use SpawnOn as well then you'd need to write your own spawner combining the two. The more general way to do it is: as <- io getArgs when (null as) $ do {- your startup code here -} which takes advantage of the fact that restarts pass --resume as a parameter, followed by the serialized xmonad state. -- 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 asjo at koldfront.dk Thu Dec 31 17:06:24 2015 From: asjo at koldfront.dk (Adam =?utf-8?Q?Sj=C3=B8gren?=) Date: Thu, 31 Dec 2015 18:06:24 +0100 Subject: [xmonad] Not running my startupHook on restart References: <87bn9660ez.fsf@tullinup.koldfront.dk> Message-ID: <874mey5yzz.fsf@tullinup.koldfront.dk> Brandon writes: > The more general way to do it is: > as <- io getArgs > when (null as) $ do > {- your startup code here -} > which takes advantage of the fact that restarts pass --resume as a > parameter, followed by the serialized xmonad state. That worked great - thanks! Best regards, Adam -- "On the quiet side. Somewhat peculiar. A good Adam Sj?gren companion, in a weird sort of way." asjo at koldfront.dk From mlists at pmade.com Thu Dec 31 20:08:08 2015 From: mlists at pmade.com (Peter Jones) Date: Thu, 31 Dec 2015 13:08:08 -0700 Subject: [xmonad] Not running my startupHook on restart References: <87bn9660ez.fsf@tullinup.koldfront.dk> Message-ID: <87twmyz8if.fsf@pmade.com> asjo at koldfront.dk (Adam Sj?gren) writes: > When I restart XMonad, I don't want those windows opened again. Also take a look at the new XMonad.Actions.DynamicProjects module: https://hackage.haskell.org/package/xmonad-contrib-0.12/docs/XMonad-Actions-DynamicProjects.html Or XMonad.Actions.TopicSpace: https://hackage.haskell.org/package/xmonad-contrib-0.12/docs/XMonad-Actions-TopicSpace.html Both of which can spawn applications on a specific workspace when it has no windows. -- Peter Jones, Founder, Devalot.com Defending the honor of good code From asjo at koldfront.dk Thu Dec 31 22:53:13 2015 From: asjo at koldfront.dk (Adam =?utf-8?Q?Sj=C3=B8gren?=) Date: Thu, 31 Dec 2015 23:53:13 +0100 Subject: [xmonad] Slowly, slowly getting calls to getWindowAttributes in XMonad to handle exceptions Message-ID: <87a8oq6xie.fsf@tullinup.koldfront.dk> While fixing the "borders of RGBA-windows are weirdly coloured"-bug?, having changed X11's getWindowAttributes to throw an exception on error, I am trying to work my way through the various calls to getWindowAttributes in the XMonad source, and handle the exceptions. With my (lacking) knowledge, it's proving somewhat difficult. Let me show you the latest call I have been trying to tackle: -- manage a new window handle (MapRequestEvent {ev_window = w}) = withDisplay $ \dpy -> do wa <- io $ getWindowAttributes dpy w -- ignore override windows -- need to ignore mapping requests by managed windows not on the current workspace managed <- isClient w when (not (wa_override_redirect wa) && not managed) $ do manage w What needs to happen is that I need to wrap this, so if getWindowAttributes throws an exception, something reasonable happens. Right. As the code does nothing if wa_override_redirect is set, maybe it makes sense to assume that if wa isn't available, wa_o_r probably isn't set(?), so we then need to go on and "do manage w" if "not managed" in that case. Ok. But how? I've tried a number of combinations of wrapping C.handle around this, similar to what I have found before?, but I certainly need (to read a lot more, or, some) help - I keep getting IO () when I need X (), or the opposite, and stuff like that. Best regards, Adam ? https://github.com/xmonad/xmonad/pull/9 depending on https://github.com/xmonad/X11/pull/35 ? An attempt at one of the other calls to getWindowAttributes: https://github.com/asjo/xmonad/commit/8c2b6047a9adf5689b6082c806dc20bb6501f6d9 (compiles and works, but really created by guess, trial and error). -- "Sprecken Sie deutsch, baby" Adam Sj?gren asjo at koldfront.dk From jschoett at gmail.com Thu Dec 31 23:09:29 2015 From: jschoett at gmail.com (=?UTF-8?Q?Jakob_Sch=c3=b6ttl?=) Date: Thu, 31 Dec 2015 15:09:29 -0800 Subject: [xmonad] How to use virtual/on-screen keyboard in Xmonad Message-ID: <5685B5A9.10202@gmail.com> Hello, I would like to use Xmonad to set up a custom, very restricted desktop environment on a Raspberry Pi with a touch screen. Because there is no hardware keyboard I need a virtual keyboard. I tried these programs: xvkbd, matchbox-keyboard, onboard, florence Some of them work with some other programs. But when it works, it's still buggy: - after typing I have to click two times to a new input field to set focus - virtual keyboard steals focus - other windows get invisible and only come back when they get focus (super+j) - doesn't work at all with some programs Is there a way to get virtual keyboards work with Xmonad, reliably and for all programs? Thank you! Jakob From bogdan.sinitsyn at gmail.com Thu Dec 31 23:25:28 2015 From: bogdan.sinitsyn at gmail.com (Bogdan Sinitsyn) Date: Fri, 01 Jan 2016 02:25:28 +0300 Subject: [xmonad] How to use virtual/on-screen keyboard in Xmonad In-Reply-To: <5685B5A9.10202@gmail.com> References: <5685B5A9.10202@gmail.com> Message-ID: <6000621.mhuxrWOlJE@navi> On Thursday, December 31, 2015 3:09:29 PM MSK Jakob Sch?ttl wrote: > Hello, > > I would like to use Xmonad to set up a custom, very restricted desktop > environment on a Raspberry Pi with a touch screen. > > Because there is no hardware keyboard I need a virtual keyboard. I tried > these programs: xvkbd, matchbox-keyboard, onboard, florence > > Some of them work with some other programs. But when it works, it's > still buggy: > > - after typing I have to click two times to a new input field to set focus > - virtual keyboard steals focus > - other windows get invisible and only come back when they get focus > (super+j) > - doesn't work at all with some programs > > Is there a way to get virtual keyboards work with Xmonad, reliably and > for all programs? > > Thank you! > > Jakob > > _______________________________________________ > xmonad mailing list > xmonad at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad It this virtual keyboard _NET_WM_WINDOW_TYPE_DOCK or smth like this? If not, it may be useful to make it be of this type. -- Bogdan Sinitsyn