March 2010 - xmonad - Haskell.org

Issue 383 in xmonad: unescaped characters are sended to xmobar
by codesite-noreply＠google.com 31 Mar '10

31 Mar '10

Status: New Owner: ---- New issue 383 by alsergbox: unescaped characters are sended to xmobar http://code.google.com/p/xmonad/issues/detail?id=383 What steps will reproduce the problem? 1. Configuring xmonad for xmobar with xmproc <- spawnPipe "xmobar -t '%StdinReader% }{' -c '[ Run StdinReader ]' -o" ... logHook = dynamicLogWithPP xmobarPP { ppOutput = hPutStrLn xmproc , ppTitle = xmobarColor "green" "" . shorten 50 , ppUrgent = xmobarColor "black" "red" } 2. Open a window with something like tags in the title, e.g. open http://bisoncpp.sourceforge.net/bisonc++.html in firefox 3. xmobar writes "couldn't parse string... " and doesn't parse it, displays as a plain text What is the expected output? What do you see instead? What version of the product are you using? On what operating system? xmonad 0.9.1 xmobar 0.9.2 Are you using an xmonad.hs? Please attach it and the output of "xmonad --recompile". Please provide any additional information below. Attachments: xmonad.hs 16.0 KB -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings

1 1

Issue 384 in xmonad: xmonad hanged on by ctrl-c in shellPrompt
by codesite-noreply＠google.com 31 Mar '10

31 Mar '10

Status: New Owner: ---- New issue 384 by alsergbox: xmonad hanged on by ctrl-c in shellPrompt http://code.google.com/p/xmonad/issues/detail?id=384 What steps will reproduce the problem? 1. Configuring xmonad to use shellPrompt, for example: , ((modMask, xK_p ), shellPrompt myXPConfig) 2. Starting xmonad in a new XServer (startx -- :1, or something like that). 3. Opening shellPrompt (modMask+P in this example) 4. Press Ctrl+C What is the expected output? What do you see instead? Expected something like closing shellPrompt. Found xmonad's hanging. What version of the product are you using? On what operating system? xmonad 0.9.1 Debian GNU/Linux testing/sid Are you using an xmonad.hs? Please attach it and the output of "xmonad --recompile". Please provide any additional information below. Attachments: xmonad.hs 16.0 KB -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings

1 1

Re: Minimized windows
by Alejandro Serrano Mena 30 Mar '10

30 Mar '10

That hook has mostly what I was looking for. However, I would like to modify it so that for windows marked as 'boring' by the BoringWindow module, it would also set the _NET_WM_STATE as _NET_WM_STATE_HIDDEN. What is the way to obtain the list of windows marked as 'boring'? > Date: Mon, 29 Mar 2010 17:41:10 +0200 > From: Joachim Breitner <mail(a)joachim-breitner.de> > Subject: Re: [xmonad] Minimized windows > To: xmonad(a)haskell.org > Message-ID: <1269877270.2503.13.camel@localhost> > Content-Type: text/plain; charset="iso-8859-15" > > Hi, > > Am Montag, den 29.03.2010, 14:49 +0200 schrieb Alejandro Serrano Mena: > > I'm trying to write a Gnome panel that shows the windows I've > > minimized with XMonad. > > At first, I've tried to get the list of minimized windows from the > > window manager using libwnck, but I've seen that XMonad does not > > change the state of windows when minimizing them, just hides them when > > painted. I'd like to know if this is correct, and if there is any way > > to accomplish the task. > > have you tried the EWMH hints module: > http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Hooks-EwmhDesktops.html > > Greetings, > Joachim > > -- > Joachim "nomeata" Breitner > mail: mail(a)joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C > JID: nomeata(a)joachim-breitner.de | http://www.joachim-breitner.de/ > Debian Developer: nomeata(a)debian.org >

3 3

Minimized windows
by Alejandro Serrano Mena 29 Mar '10

29 Mar '10

Hello, I'm trying to write a Gnome panel that shows the windows I've minimized with XMonad. At first, I've tried to get the list of minimized windows from the window manager using libwnck, but I've seen that XMonad does not change the state of windows when minimizing them, just hides them when painted. I'd like to know if this is correct, and if there is any way to accomplish the task. Thanks in advance

2 1

ANNOUNCE: XMonadConfigUpdater 0.1
by Adam Vogt 28 Mar '10

28 Mar '10

Hello all, XMonadConfigUpdater updates configs according to replacement patterns that operate on the haskell-src-exts syntax tree. Patterns to add, remove or rearrange expressions are specified as strings, but are applied to a haskell-src-exts AST. Most changes since 0.9 can be satisfied by this kind of pattern. For example, the changes in the xmobar function from 0.8 -> 0.9 are covered for all but the most obscure applications with: > dynamicLog08 = > [("xmobar xmonad","xmobar defaultConfig >>= xmonad") > ,("xmobar (xmonad . f)","xmobar (f defaultConfig) >>= xmonad") > ,("xmobar (\\x -> xmonad (f x))","xmobar (f defaultConfig) >>= xmonad") > ,("xmobar (\\x -> xmonad $ f x)","xmobar (f defaultConfig) >>= xmonad") > ] Note that any expression `f' is matched and filled in on the RHS. Hopefully this tool can be further improved, and could be either integrated with, or distributed with xmonad itself. Library changes could then be required to add rules to the collection such that some set of the config archive remains buildable. A number of desirable but currently inconvenient changes to contrib or core, such as: * direct use of functions rather than indirection through UrgencyHook class * deal with constructors or functions that should not have been exported, ex. issue 312 The repository can be found at: darcs get http://code.haskell.org/~aavogt/XMonadConfigUpdater Online demo: http://www.eng.uwaterloo.ca/~aavogt/cgi-bin/configUpdater.shtml Patches and suggestions either to improve XCU or applications are welcome. -- Adam Vogt

1 0

manaual tiling vs. auto tiling?
by Chengqi Song 28 Mar '10

28 Mar '10

I've being using xmonad for two years. but recently i found manual tiling in Musca is also handy. In fact I think it's better than xmonad's auto tiling, the only thing awkward is its support for floating window. it worths a try if you are interested. lars

3 2

per-window keyboard layouts
by Konstantin Sobolev 28 Mar '10

28 Mar '10

Hi all, I made a layout modifier that saves per-window keyboard layouts and restores them on focus changes. Quite handy when working with several keyboard layouts as there's no external program which provides this functionality AND works with XMonad: kkbswitch is abandoned, xxkb fails to detect focus changes correctly. So here it is: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=24371 However I'm not sure if I should send it to contrib: it heavily depends on FFI and requires X header files to compile. Usage: either drop as XKBLayout.hsc in contrib/XMonad/Layout , add to xmonad-contrib.cabal and rebuild Or put into ~/.xmonad/lib/XMonad/Layout as XKBLayout.hsc and run through hsc2hs Then follow instructions from the header. Basically just import and add to the layout hook. xxkb can still be used as an indicator

4 6

Compile-time verification of keymaps
by Gwern Branwen 28 Mar '10

28 Mar '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 So today I edited into my xmonad.hs a binding to the Isohunt.com XMonad.Actions.Search engine for convenience. I naturally chose xK_i for the bound key. When I reloaded, I was surprised to see that mod-i failed to do as it was supposed to. Trying it again, it brought up irssi. That was when I realized mod-i had already been bound in my xmonad.hs, to runOrRaise for irssi, and that the irssi binding happened to be later in the list and so it quietly overwrote the Isohunt binding. After picking a new & unused key, I began reflecting on this. Certainly, this is expected behavior if you're familiar with Data.Map. fromList will do that - a list may have multiple values for a single key (such as xK_i) and the last value wins. But I think in an xmonad.hs, the context is somewhat different. There the semantics are somewhat different. We use 'M.fromList [stuff, more stuff, and the rest]' syntax because Haskell supports list syntax, and it makes life easier on the user to use such a common method. But do we *really* mean to say that it is a sensible thing to bind the same key to multiple contradictory definitions? It just so happens that [xK_i isohunt, xK_i irssi] is equivalent to a destructive update style of 'i = isohunt; i = irssi' when fed through the Map functions. So I thought to myself that maybe there was some static way of specifying a list without duplicates we could use in xmonad.hs. It would be nice to know that one cannot run xmonad.hs with inconsistent sets of bindings*. This checking would, even better, be done at compile-time so one could verify this by simply loading in GHCi (good for everyone who routinely reloads in Emacs or Vim). How to do this? Someone in #haskell suggested extensible records, but that sounds quite difficult. Another approach would be to scrap the static requirement, and simply provide the user a redefined 'fromList' which runs something like 'let x = map fst list in nub x == x' and does something if there are duplicates (calls error, spawns xmessage, etc.) I decided to try a variant of the latter at compile-time, using Template Haskell. I got fairly far with the help of mmorrow, but I didn't actually succeed. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEAREKAAYFAkkgYvgACgkQvpDo5Pfl1oLE3gCgkuHMlUO1+YT4oEFLzhHqmeuB QA4An3X72j1z+StumSOmnTXlTJhHeTft =fBDz -----END PGP SIGNATURE----- The idea is that one should be able to do something like this in xmonad.hs > '{-# LANGUAGE TemplateHaskell #-} > import XMonad.Utils.VerifyKeys > .... > myKeys conf@(XConfig {modMask = m}) = M.fromList $(uniqueTupleListQ [ -- rebind standard actions > ((m .|. shiftMask,xK_p), shellPrompt greenXPConfig) > , ((m, xK_d), raiseBrowser) ] ) VerifyKeys looks something like this: > {-# LANGUAGE TemplateHaskell #-} > module XMonad.Utils.VerifyKeys where > > import Data.List(nub) > import qualified Data.Map > import Language.Haskell.TH.Lib > import Language.Haskell.TH.Syntax > > uniqueTupleListQ :: (Eq a, Lift a, Lift b) => [(a, b)] -> ExpQ > uniqueTupleListQ xs = let ys = map fst xs > ns = nub ys > in case ys == ns of > False -> fail "uniqueTupleListQ: List has conflicting entries." > True -> lift xs The idea is that since we know the keymap at compile-time, we pass it, before it gets turned into a Map (and the relevant information lost), we analyze the list. 'fail' aborts the compilation if the list is bad. You can easily test this out in a different module with some simple expressions: > keymap1, keymap2 :: [(Char, String)] > keymap1 = $(uniqueTupleListQ [('a', "foo"), ('b', "bar")] ) > keymap2 = $(uniqueTupleListQ [('a', "foo"), ('b', "bar"), ('c', "bar"), ('a', "quux")] ) Compiling, this gives us something like this: > [1 of 2] Compiling Tmp ( Tmp.hs, Tmp.o ) > [2 of 2] Compiling Main ( xmonad.hs, xmonad.o ) > Loading package base ... linking ... done. > Loading package array-0.1.0.0 ... linking ... done. > Loading package packedstring-0.1.0.0 ... linking ... done. > Loading package containers-0.1.0.1 ... linking ... done. > Loading package pretty-1.0.0.0 ... linking ... done. > Loading package template-haskell ... linking ... done. > > xmonad.hs:113:12: uniqueTupleListQ: List has conflicting entries. Line 133 is keymap2. If we remove '('a', "quux")', which conflicts with the very first entry, we get: > [1 of 2] Compiling Tmp ( Tmp.hs, Tmp.o ) > [2 of 2] Compiling Main ( xmonad.hs, xmonad.o ) > Loading package base ... linking ... done. > Loading package array-0.1.0.0 ... linking ... done. > Loading package packedstring-0.1.0.0 ... linking ... done. > Loading package containers-0.1.0.1 ... linking ... done. > Loading package pretty-1.0.0.0 ... linking ... done. > Loading package template-haskell ... linking ... done. > Linking foo ... Now, this seems to be exactly what we want, doesn't it? But ultimately I had to admit failure. Template Haskell has a number of restrictions and omissions that make it unfeasible to use. For starters: If we apply uniqueTupleList to an actual keymap (like mine), we discover that uniqueTupleList's constraints are unworkable. Per the type sig, we need 'Lift b', the second half of each tuple in the key list. But XMonad requires b to be a X (), and X () is not instantiated for Lift**. Were it, we would still need Lift instances for Word64 and also CUInt. Lift instances probably wouldn't be too hard to write. The real killer, from an xmonad.hs perspective, is the module restrictions. Fundamentally, one *cannot* use inside a $() anything defined in the same file. {modMask = m}? Nope. greenXPConfig? Nope. 'term = XMonad.terminal conf'? Nope. And so on. It is a minimal set of bindings indeed which only makes use of literals and imported functions. So until Template Haskell improves, that avenue seems to be out. I'm not sure where to go from here. Had Template Haskell worked out, the path would've been easy, a matter of having users make a relatively small modification to their xmonad.hs, and perhaps avoiding entirely TH syntax. Does anyone have a better approach, or is this a foolish thing to want static safety in? ksf suggested that Yi has a combinator approach to keybindings which could solve it, but I am unsure how that works or could be adapted for XMonad.*** * Obviously the consistency is only valuable _in_ a specific Map; if we insisted that all Maps be consistent, then we couldn't override the default Map with our own. ** I may be misinterpreting the type error; possibly we actually need Lift for (X()) *** I'm cc'ing yi-devel since I suspect the topic may be of interest. -- gwern

5 7

darcs patch: reveal: don't insert non-clients into the set of mappe...
by Tomas Janousek 28 Mar '10

28 Mar '10

Sat Mar 27 22:42:43 CET 2010 Tomas Janousek <tomi(a)nomi.cz> * reveal: don't insert non-clients into the set of mapped windows In xmonad-core, this fixes a small bug that caused doIgnored windows to get into `mapped' and never be removed from there. In the context of xmonad-contrib, this fixes a tremendous memory leak that could be triggered by using MouseResizableTile and UrgencyHook at the same time. MRT would create dummy windows that would get added to `mapped' by the reveal call in `windows'. As these were not removed (removal from `mapped' is filtered by `isClient'), they'd stay there forever and due to an inefficiency in UrgencyHook would eat up all memory sooner or later. Fun fact: this also triggered a bug in glibc after a few days such that periodic signals + fork hangs whenever the program consumes more than a certain amount of memory. -- Tomáš Janoušek, a.k.a. Liskni_si, http://work.lisk.in/

3 2

Applied: Patch bundle
by darcswatch＠nomeata.de 28 Mar '10

28 Mar '10

This 1-patch bundle was just applied to http://code.haskell.org/xmonad: 20090114215556 Daniel Schoepe <asgaroth_(a)gmx.de> * Replaced custom forever_ by library function -- This message was brought to you by DarcsWatch http://darcswatch.nomeata.de/repo_http:__code.haskell.org_xmonad.html#bundl…

1 0