- xmonad - Haskell.org

darcs patch: Add BorderUrgencyHook to XMonad.Hooks.UrgencyHook
by allbery.b＠gmail.com 27 Feb '12

27 Feb '12

1 patch for repository http://code.haskell.org/XMonadContrib: Sat Feb 25 03:26:16 EST 2012 allbery.b(a)gmail.com * Add BorderUrgencyHook to XMonad.Hooks.UrgencyHook BorderUrgencyHook is a new UrgencyHook usable with withUrgencyHook or withUrgencyHookC; it allows an urgent window to be given a different border color. This may not always work as intended, since UrgencyHook likes to assume that a window being visible is sufficient to disable urgency notification; but with suppressWhen = Never it may work well enough. There is a report that if a new window is created at the wrong time, the wrong window may be marked urgent somehow. I seem to once again be revealing bugs in underlying packages, although a quick examination of X.H.UrgencyHook doesn't seem to show any way for the wrong window to be selected.

3 2

Issue 472 in xmonad: [PATCH] XMonad/Prompt/Directory.hs fix issue on standard unixes
by codesite-noreply＠google.com 26 Feb '12

26 Feb '12

Status: New Owner: ---- New issue 472 by graude...@gmail.com: [PATCH] XMonad/Prompt/Directory.hs fix issue on standard unixes http://code.google.com/p/xmonad/issues/detail?id=472 XMonad/Prompt/Directory.hs is using /bin/bash, this is not only unportable, but also very not standard. Because of this XMonad/Prompt/Directory.hs doesn't work on FreeBSD for example. Because there is no /bin/sh, you can however install bash to /usr/local/bin/ Attached patch fixes this by simply removing /bin/ and leaving shell to figure out where is bash located I'm using xmonad and xmonad-contib 0.9.2 from FreeBSD ports Attachments: patch-XMonad__Prompt__Directory.hs 490 bytes

1 1

Issue 496 in xmonad: UpdatePointer Nearest disfunctional.
by codesite-noreply＠google.com 21 Feb '12

21 Feb '12

Status: New Owner: ---- New issue 496 by egan.mcc...@gmail.com: UpdatePointer Nearest disfunctional. http://code.google.com/p/xmonad/issues/detail?id=496 Using XMonad.Actions.UpdatePointer Nearest: 1. Open 4 windows in Tall layout. 2. Switch windows with M-j. 3. The cursor (and focus) skips the upper right window when coming from the master window, jumping straight to the middle right window. 4. Switch windows with M-k. 5. The cursor (and focus) goes to the upper right window as expected. Additionally, there are various instances where the pointer is not moved to the focused window on a workspace change. The pointer has to be moved all the way out of the unfocused window and back in to focus it. These instances are harder to pin down so I haven't any method to reproduce. Changing from Nearest to Relative fixes the problem, so I think it has something to do with the thickness of the window borders and some rounding error. I'm using xmonad 0.10-2 on Arch Linux x86-64. Configuration file attached. Attachments: xmonad.hs 3.3 KB

1 0

Managehook which only shifts window if workspace is empty
by Toby Cubitt 19 Feb '12

19 Feb '12

I'm trying to write a Managehook that only shifts a window to workspace if that workspace is empty. But I'm quickly realising I don't have a good enough grasp of Xmonad types, and Haskell monads in general, to get it to work. So far, the closest I think I've got is the following: myManageHook = [ className =? "mutt" --> doShiftEmpty "email" ] where doShiftEmpty t = when (isEmpty t) (doShift t) isEmpty t = do wsl <- gets $ W.workspaces . windowset let mws = find (\ws -> W.tag ws == t) wsl return $ maybe True (isNothing . W.stack) mws which throws a type error: "Couldn't match expected type `Bool' with actual type `m0 Bool' In the return type of a call of `isEmpty'" I think I vaguely understand the problem, namely that "when" expects a Bool as its first argument, whereas the "return" in isEmpty returns a Bool wrapped inside a monad. But removing the "return" just throws a more confusing type error. Clearly, I'm way out of my depth here, and am doing little better than cargo cult programming. Can someone who understands these things properly explain where I'm going wrong here? More generally, is there a tutorial explaining the Xmonad types and data structures, and how they go together to make up Xmoand? I've been working through some basic Haskell tutorials, but there's still quite a step from understanding a little Haskell, to understanding enough of how Xmonad works to write a simple Managehook action. Toby -- Dr T. S. Cubitt Mathematics and Quantum Information group Department of Mathematics Complutense University Madrid, Spain email: tsc25(a)cantab.net web: www.dr-qubit.org

3 4

Issue 494 in xmonad: need a way to run a layout in pure mode for inactive workspaces, with an approximation of window rectangles etc.
by codesite-noreply＠google.com 18 Feb '12

18 Feb '12

Status: New Owner: ---- New issue 494 by allber...@gmail.com: need a way to run a layout in pure mode for inactive workspaces, with an approximation of window rectangles etc. http://code.google.com/p/xmonad/issues/detail?id=494 This is not quite the usual kind of bug report; there are two user-reported issues in the IRC log I'm pasting in, which could probably be made into separate proper bug reports, but this is more a placeholder for something we should consider doing in the future. It's something of a complex issue, which is why I'm just recording the IRC log. (This also came up in another variation a couple nights ago, in the form of "how can I do PrevLayout?": some of the possible answers turn out to hinge on the same issue of wanting to run the layout "quietly" i.e. purely. It also relates to another longstanding issue where we can't provide window information for inactive workspaces to EWMH pagers.) [18 02:29] <vodik> okay, warning: vague question since im exploring an issue im having [18 02:29] <vodik> im trying to make broadcastMessages broadcast to each active layout on startup [18 02:30] <vodik> however it seems that it doesn't send things [18 02:30] <vodik> so tracing though what broadcastMessage does, it seems to, when presented a layouts like this: [18 02:31] <pzuraq> I'm using XFCE, and have 3 of the workspace switcher plugins (one for each of my monitors) but they all point toward the currently selected screen [18 02:31] <vodik> onWorkspace "foo" layout1 $ layout2 [18 02:31] <pzuraq> if I'm focussed to screen 1, all of them say 1 [18 02:31] <vodik> i thinks that the current layout on foo is layout2, not layout1 [18 02:31] <pzuraq> I want them to focus to the current screen [18 02:31] <vodik> unless i travel to that tag first [18 02:32] <geekosaur> pzuraq, workspace switchers will do that, they can't be done "cirrectly" because that requires running the layout, and unless the layout is 100% pure (and currently there is no way to check this) that requires switching to the workspace [18 02:32] <geekosaur> I have some notes about caching information but can't do anything about it for a while [18 02:33] <vodik> so how does switching tags resolve layouts? [18 02:33] <vodik> is there any way to force this? [18 02:33] <geekosaur> vodik, I think that's a variation on that question the other night about backing up through the layouts; until the workspace is made current, the layout is not yet "run" and has not selected anything yet [18 02:34] <vodik> yeah, i was there, guess its the same problem this [18 02:34] <vodik> *then [18 02:34] <geekosaur> (also see my response to pzuraq, it's actually the same problem in different guise!) [18 02:34] <pzuraq> damn [18 02:34] <pzuraq> so there's no way around it then [18 02:34] <geekosaur> not resently [18 02:34] <geekosaur> *presently [18 02:35] <pzuraq> damn. That sucks =/ [18 02:35] <pzuraq> I guess I'll have to make it :P [18 02:37] <vodik> geekosaur: well then, at least i have a decent workaround [18 02:38] <geekosaur> in theory, if every layout provided a pure approximation, we could run the layout in pure mode whenever necessary (solving both your and vodik's problems in one fell swoop), but some layouts leave the pure version stubbed and only implement the impure version, and presently xmonad always invokes the impure version (which by default invokes the pure one) [18 02:39] <geekosaur> (aaaand my network fell over twie while I was typing that in, sorry) [18 02:39] <geekosaur> twice [18 02:39] * mrdk has quit (Ping timeout: 276 seconds) [18 02:40] <geekosaur> my notes are about caching the result of running the layout, which has the shortcoming that there will be no information for a workspace until the first time it's visited (i.e. it turns your problem into vodik's) [18 02:40] <vodik> why not just visit every workspace then [18 02:41] <geekosaur> but it's easier in that it doesn't require that we go over all layouts and make sure there's a pure version of the layout function that produces a decent approximation [18 02:41] <geekosaur> vodik, that's going to produce a LOT of "screen flicker" on xmonad startup [18 02:42] <geekosaur> well, mostly on restart with populated workspaces, but still. [18 02:42] <vodik> oh i guess. i was thinking maybe some sort of quick visit behind the scene [18 02:42] <geekosaur> if it could be done behind the scenes, it would necessarily be pure [18 02:42] <vodik> technically couldn't you serialze that cache too? [18 02:43] <vodik> riiight [18 02:43] <vodik> so why not just declare all layouts must have pure approximations? :) [18 02:45] <geekosaur> the whole problem is that you need toallow impure layouts to manipulate X11, so the workspace has to actually be made current and visible :/ [and net fell over again...] [18 02:45] <geekosaur> that means auditing all existing layouts too. and it's not always clear how to do a pure approximation [18 02:45] <vodik> i guess the second part is the clincher [18 02:46] <geekosaur> I can tell you right now anything using Decoration will be a right ***** to do a pure simulation of [18 02:46] <geekosaur> (meaning, everyone's favorite Tabbed layout) [18 02:48] <geekosaur> anyway, it's something to think about for the future, but it will be a rather large undertaking [18 02:49] <geekosaur> hrm, actually, lemme copy this discussion and file a bug, so at least we have a record of it [18 02:50] <pzuraq> yeah [18 02:50] <pzuraq> a while ago there [18 02:50] <pzuraq> Still have a lot to learn [18 02:51] <vodik> pzuraq: me too, still not sure what goes on under the hood :P [18 02:53] <geekosaur> pzuraq, the tl;dr is "xmonad can only really know what's going on on a workspace by actually making it current and letting it draw all the windows" [18 02:54] * nathan28 has quit (Quit: leaving) [18 02:55] <pzuraq> geekosaur: Hmm, so that means its going to take a lot of fiddlin to get that functionality... [18 02:55] <pzuraq> fun fun :D [18 02:55] <pzuraq> just, not right now I guess [18 02:56] <pzuraq> I need to get other things done first [18 02:56] <geekosaur> so anything that needs to know the state of a non-current workspace (where windows are in your case, what the actual initial layout is in vodik's --- keep in mind a layout is a *program*, it has to be run at least once on a workspace even to determine what the actual initial layout on that workspace is) won't quite work right as xmonad currently is [18 02:56] * wyfrn has quit (Read error: Operation timed out) [18 02:57] <geekosaur> and fixing this will require some work :/ [18 02:57] <geekosaur> (another notwork drop...) [18 02:57] <pzuraq> is there some way to associate it with the individual xinerama screens? [18 02:58] <pzuraq> x-sessions [18 02:58] <pzuraq> whatever they are [18 02:58] <geekosaur> and in theory the workspace name should be "easy" to get, but since it goes through the StackSet to find it currently and the StackSet is lazily created on first visit to the workspace (mainly because it needs to know the layout, which can only be determined by running it, meaning we have to actually visit the workspace...) [18 02:59] <geekosaur> annoying [18 02:59] <pzuraq> D: [18 02:59] <pzuraq> Ihate [18 02:59] <geekosaur> associate what? [18 02:59] <pzuraq> when things are not well thought out [18 02:59] <pzuraq> which workspace is on which screen [18 03:00] <pzuraq> I'm guessing not [18 03:00] <geekosaur> again, that requires a fully populated stackset, which requires visitng the workspace [18 03:01] <geekosaur> which is why I'm making a bug for this, it's something we really should deal with but it'll be a lot of work [18 03:01] <geekosaur> maybe someone can come up with a good way to fake the simple stuff in the meantime

1 0

How do you test ManageHook using QuickCheck?
by Takafumi Arakaki 16 Feb '12

16 Feb '12

Hi, I asked the same question in StackOverflow [1] but since I haven't gotten an answer, let me ask here once again. I guess this mailing list is more appropriate place to ask. I want to test ManageHooks in my xmonad.hs and I've heard there is nice testing library called QuickCheck, so I am trying it. I worte the following code but could not make it work because XConf and XState doesn't have required field. I am not a haskell programmer, so maybe I am doing something wrong. I guess filling everything in XConf and XState means connecting to the X server which is rather heavy for a quick test. It would be better if I can write something like `StackSet i l a s sd -> ManageHook -> Bool`. import XMonad.Core import XMonad.ManageHook (doIgnore) import XMonad.Config (defaultConfig) import qualified XMonad.StackSet as W import Test.QuickCheck (Property, quickCheck) import Test.QuickCheck.Monadic (assert, monadicIO, run) prop_manage_hook :: XConf -> XState -> ManageHook -> Property prop_manage_hook c st mh = monadicIO $ do (_, newst) <- run $ runX c st $ runQuery mh $ theRoot c assert $ length (W.currentTag $ windowset newst) > 0 main :: IO () main = do quickCheck $ prop_manage_hook xc st doIgnore where xc = XConf { config = defaultConfig } st = XState {} I once experienced xmonad halted because of a zero-division error I had in my ManageHooks. That's why I want to test it before putting in my xmonad.hs. [1] http://stackoverflow.com/questions/8552627/how-do-you-test-managehook-using… Thanks, Takafumi

4 7

Comparison of "extensible window managers"
by Teika Kazura 16 Feb '12

16 Feb '12

Hi, Xmonad list. I think Xmonad is one of window managers "extensible" by users, or programmable, offering the API and allowing users to override the core code, or freely define new behaviors, though I haven't tried Xmonad actually yet. I'm a former developer of Sawfish which might be the first of such kind of WMs, using a Lisp dialect. I'm interested in comparing them, and created a wiki page for it: http://sawfish.wikia.com/wiki/Comparison_of_extensible_window_managers There Awesome and StumpWM are also studied. If someone is interested, please improve that article. Feel free to add any subjects. Or if you don't feel like editing wiki, you can comment here, and I'll do the actual edit. Of course I'll be glad to answer any questions about Sawfish. # I envy the fact that Xmonad's web site is so well tidy. I tried a lot # in improving Sawfish manual and wiki, but I felt as if I was trying # to move a mountain. With best regards, Teika (Teika kazura)

5 14

Lost XFT font support after updating Xmonad
by Leo Alekseyev 14 Feb '12

14 Feb '12

In the process of compiling the latest Xmobar from git, I needed to update my version of GHC to 7.0.4. While I was at it, I also updated my Xmonad to 0.10. Everything seems to run fine, but I lost the XFT font support (e.g. in Xmobar and in tab titles on tabbed layouts). Can anyone suggest a solution to bring XFT fonts back? I upgraded with something like cabal update cabal install xmonad cabal install xmonad-contrib --flags="-use_xft" cabal configure xmobar --flags="-with_xft" cabal install xmobar

2 1

Decoration rewrite
by Norbert Zeh 13 Feb '12

13 Feb '12

Hi folks, I have just finished a rewrite of XMonad.Layout.Decoration to improve its performance. There were a number of places in the code which took quadratic time in the number of windows in the layout. I got all this down to O(n log n) by converting uses of plain old lists to uses of Data.Map. Unfortunately, this change was not possible without changing the interface of the methods of the DecorationStyle type class. Thus, I had to fix all the modules (quite a few) that use Decoration to use the new interface. I'm done but need to test that everything behaves as expected before I push the patch. I'll also have to test how much faster the rewritten module actually is. The reason why I'm writing about this *before* putting the effort into testing all my changes is that I'd like to know how the community feels about a change in the interface of the DecorationStyle type class. As it is, there are only two choices: accept this change or continue to live with quadratic-time behaviour of all or at least most decoration modules because the latter is unavoidable with the current interface. This change in interface should only affect other modules in XMonadContrib, and I've converted them to the new interface already. User configurations should not be affected even for the majority of people who use window decorations because they will normally simply use the layout modifiers based on the decoration module - they will not directly use the DecorationStyle class. If a patch with the reimplementation of X.L.Decoration will not be rejected because of breaking the current API, then I'll continue working on this over the next little while and send the patch when I've convinced myself that things continue to work as before...only more efficiently ;) Cheers, Norbert

5 7

Is it possible to reset Xmobar without restarting Xmonad?
by Leo Alekseyev 12 Feb '12

12 Feb '12

I am using xmonad on a tablet PC where I sometimes change the screen orientation. Unfortunately, Xmobar doesn't properly rescale itself when the screen goes from portrait to landscape. If I kill it and then restart, the new Xmobar instance doesn't communicate with the Xmonad LogHook anymore. The only solution for me right now is restarting Xmonad, which is suboptimal because (1) config takes noticeable time to compile and (2) my workspace / window configuration gets completely fubared on every Xmonad restart (e.g. all the terminal windows like to move themselves to a single workspace even though there isn't a doShift directive to do so in the config (it might have something to do with my using compositing). If anyone has advice on how to reset Xmobar without Xmonad restart (or at least how to make the Xmonad restart not touch my window config), I'd love to hear it! --Leo

6 7