http://blog.gmane.org/gmane.comp.lang.haskell.xmonad hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.comp.lang.haskell.xmonad/6531 Mon Dec 1 13:09:28 CET 2008 Aleksandar Dimitrov <aleks.dimitrov< at >googlemail.com> * Fix boolean operator precedence in GridSelect keybindings The vim-like hjkl keys were ORed to the key event AND arrow keys. Aleksandar Dimitrov 2008-12-01T12:16:07 http://comments.gmane.org/gmane.comp.lang.haskell.xmonad/6529 Ian Kilgore 2008-12-01T06:37:22 http://comments.gmane.org/gmane.comp.lang.haskell.xmonad/6528 Comment #3 on issue 61 by lit...-p6vWSviCeTdg9hUCZPvPmw< at >public.gmane.org: XPrompt Ctrl+keys don't work with NumLock http://code.google.com/p/xmonad/issues/detail?id=61 This issue has been fixed and can be closed. codesite-noreply-hpIqsD4AKlfQT0dZR+AlfA< at >public.gmane.org 2008-11-30T21:33:01 http://comments.gmane.org/gmane.comp.lang.haskell.xmonad/6524 Hi, develop team! I have use XMonad some month. It's great, thanks! But i found XMonad does not support the necessary root window property, namely "_NET_ACTIVE_WINDOW". Because i have a emacs extension for SCIM-Bridge need use this root window property to compute input focus position. And can use command "xprop -root _NET_ACTIVE_WINDOW" to test this problem, will got "_NET_ACTIVE_WINDOW: no such atom on any window." message. But in GNOME, this command will get value of "_NET_ACTIVE_WINDOW". So please add this root window property in XMonad. Thanks! -- Andy. Andy Stewart 2008-11-29T14:08:24 http://comments.gmane.org/gmane.comp.lang.haskell.xmonad/6523 Status: New Owner: ---- New issue 242 by ddbremner: inter screen handling doesn't work with xrandr --right-of, works with --left-of http://code.google.com/p/xmonad/issues/detail?id=242 What steps will reproduce the problem? 1. log into to my thinkpad X61 with external monitor attached 2. xrandr --output VGA --right-of LVDS --mode 1280x1024 3. mod-shift-e in a client on the external screen What is the expected output? What do you see instead? the client should go to the laptop screen instead, it disappears (although it still shows in the kicker list) What version of the product are you using? On what operating system? xmonad 0.8 on debian. I tried with the unstable and experimental versions of the Xserver Please provide any additional information below. If I instead run xrandr --output VGA --left-of LVDS, things work as expected. If I run --right-of _after_ --left-of, it seems to work as well. If this error is due to a module from XMonadContrib, please tag this issue with 'Component-Contrib' below codesite-noreply-hpIqsD4AKlfQT0dZR+AlfA< at >public.gmane.org 2008-11-29T02:12:08 http://comments.gmane.org/gmane.comp.lang.haskell.xmonad/6521 Dominik Bruhn 2008-11-28T23:29:52 http://comments.gmane.org/gmane.comp.lang.haskell.xmonad/6520 Comment #5 on issue 234 by roma-e10UterjXHviB9QmIjCX8w< at >public.gmane.org: broken links in xmonad contrib docs http://code.google.com/p/xmonad/issues/detail?id=234 David has applied my patch which fixes the issue. Now somebody has to rebuild docs for website with darcs haddock. codesite-noreply-hpIqsD4AKlfQT0dZR+AlfA< at >public.gmane.org 2008-11-28T22:56:15 http://comments.gmane.org/gmane.comp.lang.haskell.xmonad/6518 I'm seeing a oddity with floating windows and WindowGo.raise. When I focus a floating window and trigger a cross-workspace raise operation, I get a weird flipping behavior where it switches between the workspace I was on and the workspace I was switching to in an infinite loop. It doesn't happen every time with every floating window- there's some factor there I'm not seeing. If I float an xterm and try to reproduce it, it only happens sometimes (it's bursty, though, and I'm not sure what causes it to happen). gwern< at >freenode said he reproduced it with mnemosyne, and we both reproduced it with twitux (a twitter client). For me, I can trigger it with twitux 100% of the time. Procedure: 1) Launch twitux 2) Connect (you need a twitter account, unfortunately) 3) Hit Ctrl-N to pop up the "new message" dialog 4) Click into the new message text box in the float (without this, it doesn't break for me) 5) Trigger a cross-workspace raise. Boom. (The easiest way I've found to break the loop once it happens is to Mike Lundy 2008-11-27T01:10:13 http://comments.gmane.org/gmane.comp.lang.haskell.xmonad/6514 Comment #6 on issue 200 by lucia.culakova: xmonad spins in a tight loop changing focus back and forth http://code.google.com/p/xmonad/issues/detail?id=200 I have observed a very similar effect, and the cause was use of XMonad.Actions.Warp with recent xmonad (0.8 for sure, maybe even 0.7?). Changing to use XMonad.Action.UpdateMouse fixed the problem for me, or so it seems. codesite-noreply-hpIqsD4AKlfQT0dZR+AlfA< at >public.gmane.org 2008-11-25T18:34:28 http://comments.gmane.org/gmane.comp.lang.haskell.xmonad/6513 Comment #3 on issue 241 by lucia.culakova: 0.8: moving floated window changes the current tiled master http://code.google.com/p/xmonad/issues/detail?id=241 Ah, indeed, it is fixed now. "Just after" might be an overstatement, since I have encountered this bug a while ago and tried to update do darcs without any improvement. However, there is now a different bug, after pulling the 2 patches I have excluded: Wed May 21 23:50:57 CEST 2008 Trevor Elliott <trevor-UpNH1qtbVFvQT0dZR+AlfA< at >public.gmane.org> * Raise windows in the floating layer when moving or resizing Thu Sep 11 07:39:09 CEST 2008 Devin Mullins <me-57cBFYIZrLBBDgjK7y7TUQ< at >public.gmane.org> * add W.shiftMaster, fix float/tile-reordering bug When I drag a tiled window that is not master, it *first* jumps to master position and size and then moves, which is... counterintuitive, at best. Might be worth filing a new report, then? codesite-noreply-hpIqsD4AKlfQT0dZR+AlfA< at >public.gmane.org 2008-11-25T18:28:27 http://comments.gmane.org/gmane.comp.lang.haskell.xmonad/6512 Comment #2 on issue 241 by jus...-kR7lR3n7AVJnvLZSC8Uz1g< at >public.gmane.org: 0.8: moving floated window changes the current tiled master http://code.google.com/p/xmonad/issues/detail?id=241 This was fixed in darcs right after the 0.8 release. As a workaround, you could rebind your mouse buttons to not use windows W.swapMaster. codesite-noreply-hpIqsD4AKlfQT0dZR+AlfA< at >public.gmane.org 2008-11-25T17:40:02 http://comments.gmane.org/gmane.comp.lang.haskell.xmonad/6511 Comment #1 on issue 241 by lucia.culakova: 0.8: moving floated window changes the current tiled master http://code.google.com/p/xmonad/issues/detail?id=241 This is the patch responsible for this bug: Wed May 21 23:50:57 CEST 2008 Trevor Elliott <trevor-UpNH1qtbVFvQT0dZR+AlfA< at >public.gmane.org> * Raise windows in the floating layer when moving or resizing Shall I pull this patch? (1/6) [ynWsfvpxdaqjk], or ? for help: v [Raise windows in the floating layer when moving or resizing Trevor Elliott <trevor-UpNH1qtbVFvQT0dZR+AlfA< at >public.gmane.org>**20080521215057] { hunk ./XMonad/Config.hs 228 - [ ((modMask, button1), (\w -> focus w >> mouseMoveWindow w)) + [ ((modMask, button1), (\w -> focus w >> mouseMoveWindow w + >> windows W.swapMaster)) hunk ./XMonad/Config.hs 233 - , ((modMask, button3), (\w -> focus w >> mouseResizeWindow w)) + , ((modMask, button3), (\w -> focus w >> mouseResizeWindow w + >> windows W.swa codesite-noreply-hpIqsD4AKlfQT0dZR+AlfA< at >public.gmane.org 2008-11-25T14:53:45 http://comments.gmane.org/gmane.comp.lang.haskell.xmonad/6510 Status: New Owner: ---- New issue 241 by lucia.culakova: 0.8: moving floated window changes the current tiled master http://code.google.com/p/xmonad/issues/detail?id=241 What steps will reproduce the problem? 1. Create a workspace with 3 tiled and a single float window. 2. Change one of the non-master tiled windows to master. 3. Move the float window around with a mouse. What is the expected output? What do you see instead? Nothing happens to the tiled layout, the float window moves. Instead, while the float window moves, the previous master is swapped back into master position in the tiled layout. What version of the product are you using? On what operating system? This happens in 0.8 from cabal, ghc 6.8.2 on Debian. Downgrading xmonad and xmonad-contrib to 0.7 fixes the problem. Please provide any additional information below. This is my config file: ------------------ import XMonad import XMonad.Hooks.DynamicLog import XMonad.Util.EZConfig import XMonad.Prompt import XMonad.Prompt.RunOrRaise impo codesite-noreply-hpIqsD4AKlfQT0dZR+AlfA< at >public.gmane.org 2008-11-25T13:26:15 http://comments.gmane.org/gmane.comp.lang.haskell.xmonad/6509 Status: New Owner: ---- New issue 240 by graphov: recompilation fails silently http://code.google.com/p/xmonad/issues/detail?id=240 This is not actually a defect but take some time to fix. Tomorrow I got template xmonad.hs config from the wiki (now it is changed and is correct). That file contained a module declaration with name different from "Main". That caused ghc just to compile (xmonad.o produced) it but don't link (as no Main presents). As there were no compilation errors xmonad started normally but actually config wasn't applied. I was fighting with xmonad for an hour trying to force it to use rxvt-unicode instead of xterm before noticed that my config simply doesn't compile. Maybe it's better to check if the executable actually presents in xmonad directory? Thanks. codesite-noreply-hpIqsD4AKlfQT0dZR+AlfA< at >public.gmane.org 2008-11-25T12:02:45 http://comments.gmane.org/gmane.comp.lang.haskell.xmonad/6506 Updates: Status: Fixed Comment #2 on issue 239 by byorgey: W.shiftMaster not in scope http://code.google.com/p/xmonad/issues/detail?id=239 No, the problem is that the template xmonad.hs for 0.8 on the wiki was actually the darcs version; shiftMaster was added after the 0.8 release. I've fixed the template xmonad.hs to actually work with the released 0.8 version of xmonad, and added a link to a darcs template xmonad.hs as well. codesite-noreply-hpIqsD4AKlfQT0dZR+AlfA< at >public.gmane.org 2008-11-24T22:00:26 http://comments.gmane.org/gmane.comp.lang.haskell.xmonad/6503 Mon Nov 24 20:46:32 EET 2008 Roman Cheplyaka <roma-e10UterjXHviB9QmIjCX8w< at >public.gmane.org> * Correctly implement section 4.1.7 of ICCCM Based on patch and investigation by Ivan Tarasov. Fixes #177. - do setInputFocus iff 'input' field of WM_HINTS is True - send WM_TAKE_FOCUS if needed Roman Cheplyaka 2008-11-24T19:02:01 http://comments.gmane.org/gmane.comp.lang.haskell.xmonad/6502 Comment #1 on issue 239 by dons00: W.shiftMaster not in scope http://code.google.com/p/xmonad/issues/detail?id=239 You're missing an import line. import qualfied XMonad.StackSet as W codesite-noreply-hpIqsD4AKlfQT0dZR+AlfA< at >public.gmane.org 2008-11-24T18:59:11 http://comments.gmane.org/gmane.comp.lang.haskell.xmonad/6501 Comment #6 on issue 177 by astsmtl: xmonad does not follow ICCCM and ignores WM_TAKE_FOCUS protocol http://code.google.com/p/xmonad/issues/detail?id=177 I can confirm that it fixes my problems with focus in some Java apps. I didn't try this patch before, because author said it doesn't work and already installed fluxbox to work with those apps. :) codesite-noreply-hpIqsD4AKlfQT0dZR+AlfA< at >public.gmane.org 2008-11-24T17:14:06 http://comments.gmane.org/gmane.comp.lang.haskell.xmonad/6500 Status: New Owner: ---- New issue 239 by graphov: W.shiftMaster not in scope http://code.google.com/p/xmonad/issues/detail?id=239 What steps will reproduce the problem? 1. get xmonad 0.8 (I got it from cabal) 2. get default config from wiki (for 0.8 too) 3. run. It fails to run with default confit with the following errors: xmonad.hs:238:53: Not in scope: `W.shiftMaster' xmonad.hs:240:53: Not in scope: `W.shiftMaster' xmonad.hs:243:53: Not in scope: `W.shiftMaster' codesite-noreply-hpIqsD4AKlfQT0dZR+AlfA< at >public.gmane.org 2008-11-24T09:46:08 http://comments.gmane.org/gmane.comp.lang.haskell.xmonad/6499 Comment #6 on issue 226 by vogt.adam: XMonad.Prompt lockups with ghc 6.10 http://code.google.com/p/xmonad/issues/detail?id=226 This is on x86_64 codesite-noreply-hpIqsD4AKlfQT0dZR+AlfA< at >public.gmane.org 2008-11-24T02:53:01 http://comments.gmane.org/gmane.comp.lang.haskell.xmonad/6498 Comment #4 on issue 234 by gwern0: broken links in xmonad contrib docs http://code.google.com/p/xmonad/issues/detail?id=234 Update: http://trac.haskell.org/haddock/ticket/65#comment:2 David Waern has rejected this as a bug. Do we request a Haddock feature, or just edit XMonadContrib to remove all the section links? codesite-noreply-hpIqsD4AKlfQT0dZR+AlfA< at >public.gmane.org 2008-11-24T01:07:43 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.lang.haskell.xmonad