December 2015 - xmonad

Code Freeze for v0.12 and Time to Test!
by Peter Jones 02 Mar '16

02 Mar '16

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

10 27

google code issues
by Brandon Allbery 27 Jan '16

27 Jan '16

So are we going to do anything about Google Code Issues going away in a little over two weeks? -- brandon s allbery kf8nh sine nomine associates allbery.b(a)gmail.com ballbery(a)sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

10 18

Not running my startupHook on restart
by asjo＠koldfront.dk 13 Jan '16

13 Jan '16

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(a)koldfront.dk till ett mönster på min säng"

5 9

More possibilities for border width customization
by Bogdan Sinitsyn 03 Jan '16

03 Jan '16

Sometimes it would be better to customize border width depending on window. Is it possible to merge this functionality into core? -- Bogdan Sinitsyn

3 4

How to use virtual/on-screen keyboard in Xmonad
by Jakob Schöttl 02 Jan '16

02 Jan '16

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

4 9

Slowly, slowly getting calls to getWindowAttributes in XMonad to handle exceptions
by asjo＠koldfront.dk 01 Jan '16

01 Jan '16

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/8c2b6047a9adf5689b6082c806dc20bb6501f… (compiles and works, but really created by guess, trial and error). -- "Sprecken Sie deutsch, baby" Adam Sjøgren asjo(a)koldfront.dk

2 2

Migrate from String to Data.Text [proposal]
by Matt Walker 22 Dec '15

22 Dec '15

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

4 5

`Status' Package [xmonad-contrib]
by Matt Walker 18 Dec '15

18 Dec '15

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/XM… . 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 <bold><italics>hello there!</italics></bold>, then the wrapping happens in the correct order. That is, you don't end up with <bold><italics>hello there!</bold></italics>. 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

3 2

[patch] X.P.Window: window selector for the prompt and BringToMaster action
by lewo＠abesis.fr 13 Dec '15

13 Dec '15

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.

2 2

New release to go with 7.10.2
by Tuncer Ayaz 10 Dec '15

10 Dec '15

Are there any blockers that would prevent cutting a release of current Darcs HEAD to go with the soon to be released GHC 7.10.2? It seems many users install from Darcs anyway, so it appears reasonable to me.

5 14