- xmonad - Haskell.org

Issue 389 in xmonad: Some applications are unresponsive after workspace switch
by codesite-noreply＠google.com 13 Feb '13

13 Feb '13

Status: New Owner: ---- New issue 389 by mr.schyte: Some applications are unresponsive after workspace switch http://code.google.com/p/xmonad/issues/detail?id=389 What steps will reproduce the problem? 1. open an effected application (urxvt, gvim ...) 2. switch to another workspace 3. switch back What is the expected output? What do you see instead? After switching back the selected window doesn't register keyboard input, however after selecting another window (using alt-tab; mouse focus doesn't work) everything works fine until the next workspace switch. What version of the product are you using? On what operating system? xmonad 0.9.1, Linux synapse 2.6.32-ARCH #1 SMP PREEMPT Mon Mar 15 20:44:03 CET 2010 x86_64 Intel(R) Core(TM)2 Duo CPU T8300 @ 2.40GHz GenuineIntel GNU/Linux Are you using an xmonad.hs? Please attach it and the output of "xmonad --recompile". The problem occurs even when using the default configuration. Please provide any additional information below. Some applications work, while others doesn't (xterm works, urxvt doesn't). -- 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

restackWindow / raiseWindow
by Jochen Keil 11 Feb '13

11 Feb '13

Dear list, I've written a small layout hook for raising the currently focused window: data RaiseFocused a = RaiseFocused deriving (Read, Show) instance LayoutModifier RaiseFocused a where hook _ = asks display >>= \d -> withFocused ( io . raiseWindow d ) raiseFocused :: l a -> ModifiedLayout RaiseFocused l a raiseFocused = ModifiedLayout RaiseFocused So far, so good, yet it doesn't work. The reason lies in Operations.hs, specifically in the "windows" function: io $ restackWindows d (map fst vs) This makes all my efforts useless. For now I've put the raiseWindow line into the logHook where it works, but I think this is not the right place. Any suggestions how to improve this? Would a patch for making the restacking behaviour configurable be accepted? Restacking the windows could be easily removed from the windows function and implemented as separate module. There it would be easy to implement different stacking behaviors. Best Wishes, Jochen -- -jrk Denn meine Gedanken Zerreißen die Schranken Und Mauern entzwei: Die Gedanken sind frei.

3 7

cabal sandbox
by Carsten Mattner 10 Feb '13

10 Feb '13

Trying to build and run XMonad from within a cabal sandbox using the sandbox feature found in cabal HEAD doesn't manage to build the xmonad binary from xmonad.hs. I belive it's caused by the ghc calls in XMonad.Core. Did anybody else try this? This is how you can see for yourself: * install cabal-install HEAD git clone git://github.com/haskell/cabal.git cd cabal/Cabal ghc --make Setup ./Setup configure --user ./Setup build ./Setup install cd ../cabal-install ./bootstrap.sh * use cabal sandbox for xmonad and XMonadContrib cabal sandbox-init cabal sandbox-configure cabal sandbox-OTHER_COMMANDS (add source, install, etc.) The build output will be in .cabal-sandbox.

2 3

mplayer moves 1 step right and 1 step down
by Carsten Mattner 10 Feb '13

10 Feb '13

If I return mplayer from fullscreen the floating window moves 1 step right and 1 step down. Didn't measure how many pixels it moves. Any idea?

4 7

spawn command when no completion is available (if alwaysHighlight is True); changes commandToComplete in Prompt/Shell to complete the whole word instead of using getLastWord
by Carlos López Camey 09 Feb '13

09 Feb '13

This small patch addresses http://www.haskell.org/pipermail/xmonad/2013-February/013512.html. The new behaviour also affects users that have alwaysHighlight set to False (the default) in the following way: - "xterm -e emacs" autocompleted to e.g. ["emacs","emacs23","emacs-24.2",..] before (using the last word) - "xterm -e emacs" autocompletes to nothing now which I'm not sure is a problem. Best, Carlos

3 2

shellPrompt exec with args
by Carsten Mattner 09 Feb '13

09 Feb '13

Do I have to configure anything special to use shellPrompt with extra args? For example "xterm -e emacs -nw" won't start anything and I believe it's because shellPrompt wants just a path or name of something in $PATH.

3 6

Haskell question: avoiding code duplication
by Peter Jones 06 Feb '13

06 Feb '13

I've been working on a few customizations to xmonad but as I play with Haskell I keep seeing a pattern of duplication in my code that I don't know how to resolve. Here's an example: -- | Enables 'focusFollowsMouse' for tiled windows only. For this to -- work you need to turn off 'focusFollowsMouse' in your configuration -- and then add this function to your 'handleEventHook'. focusFollowsTiledOnly :: Event -> X All focusFollowsTiledOnly e@(CrossingEvent {ev_window = w, ev_event_type = t}) | isNormalEnter = whenX bothTiled (focus w) >> continueHooks where isNormalEnter = t == enterNotify && ev_mode e == notifyNormal bothTiled = (&&) <$> notFloating w <*> currentIsTiled currentIsTiled = currentWindow >>= maybe (return True) notFloating currentWindow = gets $ W.peek . windowset notFloating w' = gets $ not . M.member w' . W.floating . windowset continueHooks = return . mempty $ True focusFollowsTiledOnly _ = return . mempty $ True The last two lines demonstrate the pattern I've been seeing. The only way I know how to remove this duplication is to move it out into a top-level function. Is that correct? Thanks! -- Peter Jones --- Love to Develop 303-219-0226 http://devalot.com

3 3

Work-Around gtk focus bugs
by Joachim Breitner 06 Feb '13

06 Feb '13

Hi, if you are also affected by gtk focus problem (e.g. text cursors missing in evolution), setting GDK_CORE_DEVICE_EVENTS=1 is a possible work-around: https://bugzilla.gnome.org/show_bug.cgi?id=677329#c13 Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nomeata(a)debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata(a)joachim-breitner.de | http://people.debian.org/~nomeata

1 0

xmodmap -e "clear mod2" is killing my xmonad mod key
by Thomas Løcke 05 Feb '13

05 Feb '13

Hey all, The rollout to my employees are going well. The BETA group are very satisfied with the setup, and all minor niggles have been sorted out so far. Except for one thing: Due to a legacy Windows XP application that isn't playing very nice with VirtualBox, we need to disable the numlock key completely. What we need is simple: 1. Activate numlock upon login. 2. Disable the numlock key so numlock stays ON under all circumstances I was convinced that this was easily solved by adding some xmodmap magic to .xinitrc: xmodmap -e "clear mod2" and while that does indeed disable the key while retaining the ON setting from my SLiM login manager, it also wreaks havoc on my xmonad mod key, which no longer works. I've got my modMask set to mod4Mask. I've tried using the default modMask, but the problem is still there. I've also tried using numlockx (instead of SLiM) to set numlock = ON, but that changes nothing: Clearing the mod2 key still mess up my xmonad. I've tried remapping the numlock keycode to nothing or to some other key, with no success. I'm at my wits end. Thomas Løcke

3 5

Re: [xmonad] Spawning an external process with focused window XID
by Mina Nagy Zaki 05 Feb '13

05 Feb '13

How would I go about spawning an external process with the XID of the focused window as an argument? I currently spawn this process and use xprop and click on the focused window to get its PID. -- Mina Nagy Zaki

2 1