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://permalink.gmane.org/gmane.comp.lang.haskell.xmonad/6532 * Aleksandar Dimitrov <aleks.dimitrov-gM/Ye1E23mwN+BqQ9rBEUg< at >public.gmane.org> [2008-12-01 13:16:07+0100] Applied, thanks! Roman Cheplyaka 2008-12-01T14:40:22 http://permalink.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://permalink.gmane.org/gmane.comp.lang.haskell.xmonad/6530 Hi, Don, Thanks, i have use "_NET_ACTIVE_WINDOW" success. -- Andy. Don Stewart <dons-UpNH1qtbVFvQT0dZR+AlfA< at >public.gmane.org> writes: Andy Stewart 2008-12-01T03:26:51 http://permalink.gmane.org/gmane.comp.lang.haskell.xmonad/6529 Ian Kilgore 2008-12-01T06:37:22 http://permalink.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://permalink.gmane.org/gmane.comp.lang.haskell.xmonad/6527 lazycat.manatee: This atom is set via the XMonad.Hooks.EwmhDesktops module. (As is the rest of the GNOME support) Don Stewart 2008-11-30T20:48:03 http://permalink.gmane.org/gmane.comp.lang.haskell.xmonad/6526 Hi Mike, thanks for the report. Could you put this on the xmonad bug tracker (http://code.google.com/p/xmonad/issues/list) so it doesn't get lost? thanks, -Brent Brent Yorgey 2008-11-30T00:54:44 http://permalink.gmane.org/gmane.comp.lang.haskell.xmonad/6525 See the docs for WindowArranger (http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Layout-WindowArranger.html), on which SimpleFloat is based. I agree it's not documented very well. What is it about the floating support that makes it impossible for you to use gimp or inkscape? I ask out of true curiosity. Personally, I use both these applications quite happily in xmonad. But I realize the loating support could be much better. There has been various talk of redoing the floating layer for a long time, maybe it will even happen someday. =) -Brent Brent Yorgey 2008-11-30T00:51:55 http://permalink.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://permalink.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://permalink.gmane.org/gmane.comp.lang.haskell.xmonad/6522 What isn't working about the current floating support? I mean the floating layer, I don't understand the point of SimpleFloat. Any case, I find that gimp is quite pleasant to use in a Tall layout with a ratio of about 11/16, but maybe that's just me. mail-kR7lR3n7AVJnvLZSC8Uz1g< at >public.gmane.org 2008-11-28T23:41:08 http://permalink.gmane.org/gmane.comp.lang.haskell.xmonad/6521 Dominik Bruhn 2008-11-28T23:29:52 http://permalink.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://permalink.gmane.org/gmane.comp.lang.haskell.xmonad/6519 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Wed, Nov 26, 2008 at 8:10 PM, Mike Lundy wrote: An even easier way to break the loop is to mouse-click in the screen - but *not* in the same area as the floating window. - -- gwern -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEAREKAAYFAkkuBSEACgkQvpDo5Pfl1oIT/QCeMVhyqn2joMV4DSuW71fI7Qpt g3sAn0YdzAczuYaJrjn9/8cupibxa0S7 =po0C -----END PGP SIGNATURE----- Gwern Branwen 2008-11-27T02:25:38 http://permalink.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 to a manual workspace move) Let me know if I can help further. Mike Lundy 2008-11-27T01:10:13 http://permalink.gmane.org/gmane.comp.lang.haskell.xmonad/6517 * Don Stewart <dons-UpNH1qtbVFvQT0dZR+AlfA< at >public.gmane.org> [2008-11-25 14:09:25-0800] We discussed it with Spencer today. It should be a matter of several minutes, but if he wants I can prepare the patch. Roman Cheplyaka 2008-11-25T22:14:00 http://permalink.gmane.org/gmane.comp.lang.haskell.xmonad/6516 Oh? Is there a patch to getWMHints I should be applying? roma: Don Stewart 2008-11-25T22:09:25 http://permalink.gmane.org/gmane.comp.lang.haskell.xmonad/6515 * Spencer Janssen <spencerjanssen-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> [2008-11-25 04:57:47-0600] Here's amended patch. 2 all: feel free to test/use it, but be aware that it will leak memory until getWMHints is fixed in X11. Roman Cheplyaka 2008-11-25T21:29:02 http://permalink.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://permalink.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://permalink.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 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.lang.haskell.xmonad