September 2010 - xmonad

Re: Issue 69 in xmonad: Key binding improvements
by codesite-noreply＠google.com 10 Dec '10

10 Dec '10

Comment #9 on issue 69 by mark.stosberg: Key binding improvements http://code.google.com/p/xmonad/issues/detail?id=69 I'm struggling to try Xmonad because I don't have a windows key and the "loving caress" of xmodmap (as the original poster puts it) is not so gentle. As someone new to Xmonad and Haskell, the "sufficient" workaround is not simple at all: - delete all of the default keybindings - add a single keybinding for your desired prefix key that activates a submap - add all the desired keybindings to your submap I wouldn't know how to start with implementing that. I even tried the "extra user-friendly" BlueTile alternative. It also assumed I had a Windows key... -- 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 4

Re: Issue 291 in xmonad: Layout.Tabbed has drawing problems when used with Layout.MultiToggle
by codesite-noreply＠google.com 04 Nov '10

04 Nov '10

Updates: Labels: Type-Defect Component-Contrib Comment #1 on issue 291 by vogt.adam: Layout.Tabbed has drawing problems when used with Layout.MultiToggle http://code.google.com/p/xmonad/issues/detail?id=291 Can you still reproduce this if you include this patch: Sat Dec 19 19:47:33 EST 2009 Tomas Janousek <tomi(a)nomi.cz> * Fix MultiToggle crashes with decorated layouts The problem was that certain layouts keep their "world" state in their value, which was thrown away and forgotten after ReleaseResources during toggle. In particular, decorated layouts store some X11 handles in them and allocate/deallocate it as appropriate. If any modification to their state is ignored, they may try to deallocate already deallocated memory, which results in a crash somewhere inside Xlib. This patch makes Transformers reversible so that nothing is ever ignored. As a side effect, layout transformers now do receive messages and messages for the base layout do not need the undo/reapply cycle -- we just pass messages to the current transformed layout and unapply the transformer when needed. (This, however, doesn't mean that the base layout is not asked to release resources on a transformer change -- we still need the transformer to release its resources and there's no way to do this without asking the base layout as well.) -- 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 5

Re: Issue 197 in xmonad: Blocking on nextEvent stops other threads from running
by codesite-noreply＠google.com 03 Nov '10

03 Nov '10

Comment #4 on issue 197 by byorgey: Blocking on nextEvent stops other threads from running http://code.google.com/p/xmonad/issues/detail?id=197 What's the status of this ticket? Is this a WontFix? Or is there something that could be improved here? -- 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 4

darcs patch: windowbringer-menu-choice
by mathstuf＠gmail.com 24 Oct '10

24 Oct '10

1 patch for repository http://code.haskell.org/XMonadContrib: Sat Sep 4 21:35:22 EDT 2010 mathstuf(a)gmail.com * windowbringer-menu-choice Add functions to allow users to use a menu other than dmenu and pass arguments to the menu.

2 1

Re: Issue 4 in xmonad: Separate focus for tiled and floating layers
by codesite-noreply＠google.com 16 Oct '10

16 Oct '10

Comment #16 on issue 4 by scuz.there: Separate focus for tiled and floating layers http://code.google.com/p/xmonad/issues/detail?id=4 It might be more useful to have transients for a window hidden when that window is not focused. Similar to Photoshop on Mac. -- 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 8

ppVisible with 3 screens
by Felix Blanke 10 Oct '10

10 Oct '10

Hi, I was using 2 screens with xmonad and xmobar. The settings ppCurrent = xmobarColor "#CC0000" "" . wrap "[" "]" , ppVisible = xmobarColor "#EE9A00" "" . wrap "[" "]" , ppTitle = shorten 80 , ppSep = "<fc=#AFAF87> | </fc>" , ppHiddenNoWindows = xmobarColor "#AFAF87" "" , ppUrgent = xmobarColor "#EE9A00" "" . wrap "[" "]" worked good for 2 screens: The active workspace is red and the inactive is orange. But now, with 3 screens, there are 2 inactive workspaces and they both are orange. Is there a way to say: inactive on screen 0 = blue inactive on screen 1 = ornage inactive on screen 3 = green or something similar. Thanks for your help! Regards, Felix

4 14

Applications cover xmobar
by Guillaume Thouvenin 30 Sep '10

30 Sep '10

Hello, I'm new to xmonad and I observe a strange behaviour with the status bar. I started xmobar as follow: in my xmonad.hs I have: main = do xmproc <- spawnPipe "xmobar" xmonad $ azertyConfig { workspaces = myWorkspaces, terminal = myTerminal, modMask = myModMask, logHook = dynamicLogWithPP $ xmobarPP { ppOutput = hPutStrLn xmproc, ppTitle = xmobarColor "green" "" . shorten 50 }, manageHook = manageDocks <+> myManageHook <+> manageHook azertyConfig } in my .xmobrrc I have: Config { font = "-misc-fixed-*-*-*-*-10-*-*-*-*-*-*-*" , bgColor = "black" , fgColor = "grey" , position = TopW L 90 , lowerOnStart = True , commands = [ Run Weather "LFLG" ["-t","<station>: <tempC>C","-L","18","-H","25","--normal","green","--high","red","--low","lightblue"] 36000 , Run Network "eth0" ["-L","0","-H","32","--normal","green","--high","red"] 10 , Run Cpu ["-L","3","-H","50","--normal","green","--high","red"] 10 , Run Memory ["-t","Mem: <usedratio>%"] 10 , Run Swap [] 10 , Run Com "uname" ["-s","-r"] "" 36000 , Run Date "%a %b %_d %Y %H:%M:%S" "date" 10 , Run StdinReader ] , sepChar = "%" , alignSep = "}{" , template = "%StdinReader% }{%cpu% | %memory% * %swap% | %eth0% | <fc=#ee9a00>%date%</fc>| %LFLG% | %uname%" } I can see the status bar in a workspace when it is empty but when I start an application (xterm, firefox, ...) the application covers the status bar and therefore I can not see it. I tried to modify lowerOnStart = False but this hides the top of my application. I'm using xmonad 0.9.1-2 and xmobar 0.9.2-1 with ubuntu 10.04. Thanks for your help, Guillaume

2 2

Issue 366 in xmonad: XMonad.Layout.NoFrillsDecoration depends on SimpleDecoration
by codesite-noreply＠google.com 29 Sep '10

29 Sep '10

Status: New Owner: ---- New issue 366 by j...@kitenet.net: XMonad.Layout.NoFrillsDecoration depends on SimpleDecoration http://code.google.com/p/xmonad/issues/detail?id=366 What steps will reproduce the problem? 1.import XMonad.Layout.NoFrillsDecoration 2.do not import XMonad.Layout.SimpleDecoration 3. What is the expected output? What do you see instead? xmonad.hs:41:10: Not in scope: `defaultTheme' xmonad.hs:42:4: Not in scope: `activeColor' xmonad.hs:43:4: Not in scope: `inactiveColor' xmonad.hs:44:4: Not in scope: `activeBorderColor' xmonad.hs:45:4: Not in scope: `inactiveBorderColor' Etc. This goes away if SimpleDecoration is also imported. 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". Please provide any additional information below. -- 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 3

KeyEvent stream manipulation
by Daniel 26 Sep '10

26 Sep '10

For what I want to do I need to have exclusive access to the keyboard events so that I can rewrite them. I have been experimenting a bit with this in XMonad, but passive grabs don't work. The problem with passive grabs is with overlapping events. This is what happens: * press key A * grab converts from passive to active * KeyEvent keyPress A is delivered to XMonad * B is pressed * KeyEvent keyPress B gets delivered to XMonad (B is registered as passive grab as well, but gets delivered, because technically, we're in an active grab now) * A is released * KeyEvent keyRelease A gets delivered to XMonad * active grab on A reverts to passive (incl some FocusEvents & KeymapNotify to inform us that B is still held) * B is released * KeyEvent keyRelease B gets NOT delivered to XMonad, it's a regular KeyEvent, no grab is active, and the passive grab on B is not triggered, because its keyPress event occurred during another (shadowing) activeGrab. (Actually, if you keep pressing B, after about a second or so, X realizes that there should be a grab active and enters the grab. Unfortunately, this is not fast enough when typing. Just to be clear, this is a problem of passive grabs, not with XMonad. Because of this behaviour it seems that the only thing that gets me there within X is a permanent active grab (keyboardGrab). Other extensions use active grabs, but they only do this for a limited time, usually after being triggered (eg. CycleRecentWS, Submap, GridHS, CycleWindows). So my questions: * Is such a permanent active grab a good idea within X? I'm worrying about problems interacting with other programs who might attempt grabs or XMonad losing the grab and not knowing about it. * If this is not a good idea, what should I look into to get this capability (exclusive access to transform the keyboard event stream, before it reaches any application). * Where/who should I ask to get an informed answer if not here? My end target are X applications, and I expect that there will be a tight integration with the window manager (likely XMonad). But I'm willing to look at a variety of points to hook into the event stream. Thanks

2 4

Issue 400 in xmonad: LayoutHints don't respect windows' hint changes without changing the workspace state
by codesite-noreply＠google.com 26 Sep '10

26 Sep '10

Status: New Owner: ---- New issue 400 by aleks.dimitrov: LayoutHints don't respect windows' hint changes without changing the workspace state http://code.google.com/p/xmonad/issues/detail?id=400 What steps will reproduce the problem? 1. Use a minimal configuration like: main = xmonad $ defaultConfig { layoutHook = layoutHints (XMonad.Tall 1 (1/2) (3/100)) } 2. Open Rhythmbox and press CTRL-D (to collapse the view to 'compact view') 3. Change the workspace state (toggle struts, change focus, launch stuff) What is the expected output? What do you see instead? I'd like XMonad to recognize Rhythmbox' state change without re-evaluation of the workspace state. XMonad however doesn't seem to be notified of Rhythmbox' preferred size, or maybe just doesn't react to it. Here's a couple of screenshots to illustrate the problem: http://imgur.com/THPdml&y5e0U&r6n58 First image shows what happens when RBX changes its appearance and XMonad doesn't react (these huge grey windows are exactly what I'm trying to avoid using hinted layouts.) Second image shows the desktop after a state change. That's what I'd like to see! Third image shows RBX expanding to its extended view again, but the window doesn't get bigger! It stays small and requires a workspace state change to go back to normal. What version of the product are you using? On what operating system? xmonad 0.9.1 (Ubuntu 10.04) Are you using an xmonad.hs? Please attach it and the output of "xmonad --recompile". Minimal reproducing config: > import XMonad > import XMonad.Layout.LayoutHints > main = xmonad $ defaultConfig > { layoutHook = layoutHints (XMonad.Tall 1 (1/2) (3/100)) } xmonad --recompile remains silent :-)

1 5