November 2012 - xmonad

Issue 507 in xmonad: Pattern match failure in do expression at XMonad/Prompt.hs:601:3-14
by codesite-noreply＠google.com 26 Dec '12

26 Dec '12

Status: New Owner: ---- New issue 507 by smp...(a)gmail.com: Pattern match failure in do expression at XMonad/Prompt.hs:601:3-14 http://code.google.com/p/xmonad/issues/detail?id=507 **What steps will reproduce the problem?** I'm not sure that I can exactly describe how I get it. Generally speaking, it's `shellPrompt' call and fast `t' pressing. Than I get xmonad totally freezed and message in terminal where I call `xinit', which run xmonad: Pattern match failure in do expression at XMonad/Prompt.hs:601:3-14 At 601 line of Prompt.hs there is unsafe pattern matching: Just bgcolor <- io $ initColor d (bgColor c) Just border <- io $ initColor d (borderColor c) **What is the expected output? What do you see instead?** What I want is some `fromJust' there or hadling this situation with `case'. It's xmonad-contrib-0.10-r1 build from gentoo-haskell overlay. (https://github.com/gentoo-haskell/gentoo-haskell/tree/master/x11-wm/xmonad-…)

1 11

Issue 360 in xmonad: shellPromptHere from XMonad.Actions.SpawnOn freezes upon files with Chinese names
by codesite-noreply＠google.com 15 Dec '12

15 Dec '12

Status: New Owner: ---- New issue 360 by wei.hoo: shellPromptHere from XMonad.Actions.SpawnOn freezes upon files with Chinese names http://code.google.com/p/xmonad/issues/detail?id=360 What steps will reproduce the problem? 1. Bind a key combination to shellPromptHere 2. mkdir /tmp/new; cd /tmp/new 3. touch 1; touch 测试 4. Invoke shellPromptHere, type in "emacs /tmp/new/", press TAB What is the expected output? What do you see instead? Observe that the shell prompt window freezes. No keybindings are accepted, such as C-a, C-e, C-g. However, XMonad keybindings are still effective. At this point we have to press M-q to restart XMonad. What version of the product are you using? On what operating system? xmonad-darcs and xmona-contrib-darcs on Arch Linux. GHC-6.12. Are you using an xmonad.hs? Please attach it and the output of "xmonad --recompile". Please provide any additional information below. If we remove /tmp/new/1 and only keep /tmp/new/测试, typing "emacs /tmp/new/ [TAB]" doesn't freeze the shell prompt. The Chinese-named file isn't shown in the completion, but we can still press C-g to cancel the shell prompt. The font I'm using does support Chinese. PS: I kind of remember this wasn't a problem with ghc-6.10, but I'm not sure. Attachments: xmonad.hs 6.8 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 509 in xmonad: Sometimes cannot switch focus using keyboard shortcuts
by codesite-noreply＠google.com 08 Dec '12

08 Dec '12

Status: New Owner: ---- New issue 509 by dcl...(a)gmail.com: Sometimes cannot switch focus using keyboard shortcuts http://code.google.com/p/xmonad/issues/detail?id=509 What steps will reproduce the problem? 1. Launch terminal 2. Launch another program using Mod-S-p 3. Try to switch window focus using M-S-j What is the expected output? What do you see instead? Window should switch focus. Window does not switch focus. Need to use mouse to regain control of focus. What version of the product are you using? On what operating system? xmonad 0.10. Ubuntu Precise. Are you using an xmonad.hs? Please attach it and the output of "xmonad --recompile". No output of xmonad --recompile. File is attached. Please provide any additional information below. The problem seems to happen intermittently and cannot always be reproduced. Attachments: xmonad.hs 3.3 KB

1 2

Re: Issue 177 in xmonad: xmonad does not follow ICCCM and ignores WM_TAKE_FOCUS protocol
by codesite-noreply＠google.com 05 Dec '12

05 Dec '12

Comment #24 on issue 177 by vogt.adam: xmonad does not follow ICCCM and ignores WM_TAKE_FOCUS protocol http://code.google.com/p/xmonad/issues/detail?id=177 Geoff Reedy's last patch doesn't apply cleanly against latest darcs (due to the merging of extensible state stuff). Attached is a patch bundle including the old ones that probably works as the old one did. Attachments: track-currently-processing-event.dpatch 16.1 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

4 108

Issue 520 in xmonad: The _NET_ACTIVE_WINDOW property is not set
by codesite-noreply＠google.com 29 Nov '12

29 Nov '12

Status: New Owner: ---- New issue 520 by sbrainstream: The _NET_ACTIVE_WINDOW property is not set http://code.google.com/p/xmonad/issues/detail?id=520 Hello! I am writing the program that must grab screenshot from a focused window. I am using the screenGetActiveWindow (gtk2hs) which uses the _NET_ACTIVE_WINDOW property to determine the active window. My program works fine everywhere except xmonad. Please, add the _NET_ACTIVE_WINDOW property to the root window.

1 2

xmobar on GNOME3
by Tony Morris 28 Nov '12

28 Nov '12

I am trying to get xmobar running on GNOME3. However, xmonad starts the process, then it quits. I am not sure why, but I know that it quits because I changed the output handler (ppOutput) to first use writeFile then to the xmobar Handle. I saw the contents that would have been piped to xmobar in the file. If I start xmobar manually after xmonad has started, it starts fine, reading "Updating..." awaiting input. I have minimised ~/.xmonad/xmonad.hs and I have tried many variants to try to resolve the issue: https://gist.github.com/4129597 I have also tried fiddling with ~/.xmobarrc but this is how it currently stands: https://gist.github.com/4129924 Any tips are immensely appreciated, because I have run out of ideas! -- Tony Morris http://tmorris.net/

4 3

Prospective development of Xmonad
by Jochen Keil 28 Nov '12

28 Nov '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear list, recently I looked around in the world of tiling window managers. In particular I looked at wmii, i3 and awesome. They offer various features which I was very fond off, yet none was so feature complete that I was convinced to make the switch. Then I started to think about the current state of xmonad and came to the conclusion that compared to the aforementioned window manager it seems that some dust has settled upon xmonad. Finally I came up with a small list of features I'd like to implement for xmonad, but I fear that this would break many if not all modules in contrib. I'll discuss every item in detail. 1) wmii like tags The current workspace model seems a bit inflexible to me. After trying wmii's window tagging model I think that this is a far more flexible, dynamic and better approach to managing windows. Want your browser visible with your editor/terminal windows you use in project A? No problem, associate tag A with your browser, same for tag C, etc. 2) Xrandr support I've extended the current bindings (Graphics.X11.Xrandr) so that they would be usable for what I intend to do with xmonad. There's a pull request on github and I hope dwagner (who reads this list too, afaik, hint, hint ;) will merge it soon. My idea about Xrandr support for xmonad would be similar to how it's done in i3. I'd create a separate config for every output (in the Xrandr terminology, e.g. DVI1 or LVDS, etc.). Therefore, every output would be associated with a set of windows, and a layout which would be used to generate the "view" for the windows. If an output becomes inactive the windows could easily be shown on another output (e.g. by using something like a hierarchical ManageHook, like try 1; try 2; fallback 3) This would especially shine together with wmii like tags. To motivate this idea a bit more: Imagine attaching your external monitor to your laptop and all your windows will be automatically sorted to the right screen, e.g. the browser and the editor to the external monitor, your email client to your laptops monitor. 3) A tree hierarchy for windows I had some issues with the stackset over the past years, mainly because it makes it hard to write an column layout which simply splits the current window either automatically or manually. Furthermore a tree can be simply transformed to a stack (the other way round is nearly impossible). That way most of the (at least pure) layouts could be kept, layouts with side effects (especially on the X monad) probably not. 4) Reparenting This would be nice for having window titles, etc. Only for the sake of completeness for the moment, since I haven't thought about this much yet. 5) XCB instead of Xlib This is kind of optional. The XHB (haskell xcb bindings) lack some features which would make it hard to fully convert xmonad to xcb. However, there is Xlib-xcb which facilitates the usage of Xlib functions with xcb. All that's required is a simple hsc2hs wrapper to this. I apologize for the length of this email, but I wanted to point out my motivation and make my ideas clear. I'm also asking explicitly for feedback from current developers. If you have an idea on how to implement these ideas without breaking contrib, that would be fine. Or maybe you want to start out with something on this list, that would be even better :) I also thought about creating a clone/fork of xmonad, but that's something I'd like to avoid, since I believe that the world does not need yet another wm. Best wishes, Jochen -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlCugUkACgkQtVwvsA+W4CDoegCfXHsWj4UcQmM0xzVva78a/HuT 9wYAmwQqbJfB6cgsgIVpjlXElb8nSgdL =XKfv -----END PGP SIGNATURE-----

5 4

inconsistent behaviour of mod+shift+return
by gunjan kumar 25 Nov '12

25 Nov '12

i am a newbee with xmonad. The issue is that when i use mod+shift+return to open xerms, then sometimes (10% times)it works. But usually the screen flickers and no xterm opens. i have to press the m0d+shift+return multiple times,and then i get like 2 or 3 xterms opened. So its not very consistent. ps:I have not changed any default key bindings, everything else seems fine.

1 0

darcs patch: HCAR.tex: update to Janis's master version per his ins...
by gwern0＠gmail.com 18 Nov '12

18 Nov '12

1 patch for repository community.haskell.org:/srv/code/xmonad: Sat Nov 17 20:03:10 EST 2012 gwern0(a)gmail.com * HCAR.tex: update to Janis's master version per his instructions

3 2

Issue 515 in xmonad: XMonad freezes occasionally when using Gridselect (XMonadContrib)
by codesite-noreply＠google.com 17 Nov '12

17 Nov '12

Status: New Owner: ---- New issue 515 by bmathiasen: XMonad freezes occasionally when using Gridselect (XMonadContrib) http://code.google.com/p/xmonad/issues/detail?id=515 What steps will reproduce the problem? 1. Toggling Gridselect (goToSelected/gridselectWorkspace) 2. Attempt to move to another window or workspace. What is the expected output? What do you see instead? Expected output: Normal 2D grid of windows/workspaces, that I can swap to using the keyboard. What I see: The 2D grid opens, but any subsequent input from the keyboard will occasionally cause XMonad to freeze; windows and workspaces will become unresponsive. It is possible to go to another tty to kill xmonad, after which a WM can be launched on the appropriate display. What version of the product are you using? On what operating system? XMonad version 0.10 (built from source, package manager, and Cabal) on the following OS's: - LinuxMint (DebianTesting edition) using XFCE4. - Xubuntu (11.10 and 12.04). - Ubuntu (12.04). All setups tried on two separate laptops, Lenovo Thinkpad X220 and T400s. Are you using an xmonad.hs? Please attach it and the output of "xmonad --recompile". No output. Please provide any additional information below. My xmonad.hs uses custom functions for gridselecting windows and workspaces, but the same error occur with the default configuration. Upon freeze, there is no relevant error logging output in /var/log/messages, ~/.Xsession-errors or ~/.xmonad/xmonad.errors. Attachments: xmonad.hs 8.9 KB

1 8