February 2012 - xmonad

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

18 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 17 Feb '12

17 Feb '12

Status: New Owner: ---- New issue 494 by allber...(a)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 15 Feb '12

15 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 13 Feb '12

13 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 12 Feb '12

12 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

Delays in focus update...
by Allen S. Rout 08 Feb '12

08 Feb '12

I'm running xmonad now on a 4-monitor setup which is slowly approaching perfect-for-me. Yay, and thanks! But I've noticed a certain lack of responsiveness when I make sweeping motions with the mouse, and I've now done a bit of an experiment that seems to narrow it down. To observe this behavior: + open up a lot of shells. Mod-shift-enter 15 or 20 times on an empty workspace will do. + Pick a side of the screen which is an edge, not adjacent to another screen + Move your mouse to that screen, on the -opposite- side from the edge. + Swiftly move your mouse to the edge, like _fast_. 10th of a second or so. You're crossing many terminals. + Watch the successive terminals momentarily get focus; count the time (seconds if you go nuts on the count) it takes for focus to get where your mouse is. .... So it seems it takes constant, substantial subsecond time between window X gets focus, and when xmonad is willing to consider that it might have lost it. Is there some timing loop in there? Or is there something fundamental and X-y happening that limits this? In other WMs, I'm accustomed to focus shifting nearly instantaneously, but I might be missing something. - Allen S. Rout

6 17

Issue 493 in xmonad: spawnPipe opens another instance of the applicatioon
by codesite-noreply＠google.com 07 Feb '12

07 Feb '12

Status: New Owner: ---- New issue 493 by argu...(a)gmail.com: spawnPipe opens another instance of the applicatioon http://code.google.com/p/xmonad/issues/detail?id=493 What steps will reproduce the problem? 1. Have a spawnPipe on xmonad.hs 2. Hit Mod+Q 3. See a duplicate xmobar running. What is the expected output? What do you see instead? When pressing Mod+Q it should kill my xmobar instance and open another one. When pressing Mod+Q it start another xmobar instance. What version of the product are you using? On what operating system? xmonad-darcs 20111213-1 3.2.2-1-ARCH Are you using an xmonad.hs? Please attach it and the output of "xmonad --recompile". No output on "xmonad --recompile" Please provide any additional information below. Attachments: xmonad.hs 14.1 KB

1 5

Issue 450 in xmonad: ManageDocks should check for multi window types in _NET_WM_WINDOW_TYPE
by codesite-noreply＠google.com 07 Feb '12

07 Feb '12

Status: New Owner: ---- New issue 450 by icarnales: ManageDocks should check for multi window types in _NET_WM_WINDOW_TYPE http://code.google.com/p/xmonad/issues/detail?id=450 According to the spec: _NET_WM_WINDOW_TYPE _NET_WM_WINDOW_TYPE, ATOM[]/32 This SHOULD be set by the Client before mapping to a list of atoms indicating the functional type of the window. This property SHOULD be used by the window manager in determining the decoration, stacking position and other behavior of the window. The Client SHOULD specify window types in order of preference (the first being most preferable) but MUST include at least one of the basic window type atoms from the list below. This is to allow for extension of the list of types whilst providing default behavior for Window Managers that do not recognize the extensions. http://standards.freedesktop.org/wm-spec/1.3/ar01s05.html What steps will reproduce the problem? 1. Launch a program with multiple window types like DOCK and NORMAL (tested with unity-2d panel and launcher) What is the expected output? What do you see instead? The window should be ignored and a gap must be created to accommodate it. Instead the window is treated normally. What version of the product are you using? On what operating system? 0.9 Are you using an xmonad.hs? Please attach it and the output of "xmonad --recompile". Any config with ManageDocks (tested with desktopConfig and manual ManageDocks) will do. Please provide any additional information below. I think checkDock function should be in a more generic place like Hooks/ManageHelpers that are currently using the isInProperty function to check for property values.

1 1