February 2013 - xmonad

Issue 532 in xmonad: _NET_WM_STATE_DEMANDS_ATTENTION support
by codesite-noreply＠google.com 18 Feb '13

18 Feb '13

Status: New Owner: ---- New issue 532 by maar...(a)de-vri.es: _NET_WM_STATE_DEMANDS_ATTENTION support http://code.google.com/p/xmonad/issues/detail?id=532 The _NET_WM_STATE_DEMANDS_ATTENTION atom is part of the EWMH specification and can be used to indicate that something happened in a window. It's apparently a somewhat weaker hint than the urgency flag of WM_HINTS, because EWMH say that windows expecting immediate attention should still use WM_HINTS. Either way, the current UrgencyHook doesn't respect _NET_WM_STATE_DEMANDS_ATTENTION. This impacts amongst others all Qt applications, since Qt only uses ..._DEMANDS_ATTENTION and never WM_HINTS. I patched UrgencyHook to also respect _NET_WM_STATE_DEMANDS_ATTENTION. I'm not much of a Haskell expert though, so I suggest someone takes a good look at it and point out what I did wrong. Attachments: ewmh_demands_attention.dpatch 7.9 KB

1 2

Testing GHC HEAD
by Carsten Mattner 17 Feb '13

17 Feb '13

xmonad built fine with GHC HEAD but XMonadContrib failed with the following build error: XMonad/Layout/MultiToggle.hs:162:9: Could not deduce (HList b w0) arising from the ambiguity check for `??' from the context (HList b w) bound by the type signature for ?? :: HList b w => a -> b -> HCons a b at XMonad/Layout/MultiToggle.hs:162:9-42 The type variable `w0' is ambiguous In the ambiguity check for: forall a b w. HList b w => a -> b -> HCons a b In the type signature for `??': ?? :: HList b w => a -> b -> HCons a b Can anyone suggest a fix?

2 1

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