September 2008 - xmonad

Issue 221 in xmonad: Grabbing/releasing grab makes mouse inactive
by codesite-noreply＠google.com 20 Sep '08

20 Sep '08

Issue 221: Grabbing/releasing grab makes mouse inactive http://code.google.com/p/xmonad/issues/detail?id=221 Comment #4 by bardur.arantsson: I did a more thorough test with VirtualBox in KDE, and it exhibits the same issue. So this is probably an issue with the VirtualBox/X server. Apologies for the bogus report. I'll try reporting this as a VirtualBox/Xorg bug instead. (Just as an aside: Once the X server is in the broken state, xev reports no mouse events at all.) -- 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 0

Issue 221 in xmonad: Grabbing/releasing grab makes mouse inactive
by codesite-noreply＠google.com 20 Sep '08

20 Sep '08

Issue 221: Grabbing/releasing grab makes mouse inactive http://code.google.com/p/xmonad/issues/detail?id=221 Comment #3 by domi...(a)dbruhn.de: Perhaps the xev application (run it on a console) might help -- 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 0

Issue 221 in xmonad: Grabbing/releasing grab makes mouse inactive
by codesite-noreply＠google.com 20 Sep '08

20 Sep '08

Issue 221: Grabbing/releasing grab makes mouse inactive http://code.google.com/p/xmonad/issues/detail?id=221 Comment #2 by bardur.arantsson: I've just tested with KVM myself, and everything seems to work fine there, so there is probably something peculiar about how VirtualBox does the grab/release. As mentioned the issue doesn't seem to appear in KDE/kwin, so I suspect there is still something wrong with the focus handling in xmonad (rather than VirtualBox being broken). I'll try to do a bit further testing in KDE/kwin (some of the installed X11 stuff has changed since my last test) and see what I come up with. Meanwhile, is there any kind of X11 event sniffing or anything like that I can do to help debug this? -- 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 0

Issue 221 in xmonad: Grabbing/releasing grab makes mouse inactive
by codesite-noreply＠google.com 20 Sep '08

20 Sep '08

Issue 221: Grabbing/releasing grab makes mouse inactive http://code.google.com/p/xmonad/issues/detail?id=221 Comment #1 by domi...(a)dbruhn.de: I can NOT confirm this using QEmu/KVM (Release Key is here left ctrl+left alt) using xmonad, xmonadcontrib from darcs on debian unstable. -- 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 0

Issue 221 in xmonad: Grabbing/releasing grab makes mouse inactive
by codesite-noreply＠google.com 20 Sep '08

20 Sep '08

Issue 221: Grabbing/releasing grab makes mouse inactive http://code.google.com/p/xmonad/issues/detail?id=221 New issue report by bardur.arantsson: What steps will reproduce the problem? 1. Run anything which grabs mouse and keyboard. I used VirtualBox with a running virtual machine. 2. Let the program grab the mouse and keyboard, e.g. by clicking in a virtual machine. 3. Release grab by pressing the "release grab" key. For VirtualBox this is the Right Ctrl key (by default). What is the expected output? What do you see instead? I'd expect grab to be released and I'd expect the mouse and keyboard to work as before being grabbed. What happens is this: The keyboard and mouse grab is released. The mouse pointer moves about when I move the mouse, but no mouse events are registered by the X server. The keyboard seems to work fine for navigating around in Xmonad/terminals(konsole) and emacs, but the keyboard does *not* work properly in Firefox/Konqueror/Ktorrent (for example). In the affected programs (Firefox, etc.) the keyboard works briefly, but after a few seconds (at most) all further keypresses are ignored completely. If focus is switched away briefly and switched back to Firefox, the keyboard works again for a few seconds, but then stops working again (repeat ad nauseam). I have not been able to reproduce this behavior in KDE (kwin), but it happens very frequently when releasing grab from VirtualBox in Xmonad. The behavior also happens even if you enable "mouse integration" (i.e. smooth movement of the mouse from/to the virtual machine without having to explicitly release grab) in VirtualBox, but I believe this also uses X11 grab behind the scenes even though you can't really see it. I'm not sure I have any other programs which grab the keyboard/mouse, so I cannot be sure whether this issue is solely related to VirtualBox/xmonad interaction. I've also tried various combinations of layouts, etc. and I don't believe it has anything to do with layout choices. What version of the product are you using? On what operating system? xmonad-0.8 + xmonad-contrib-0.8 compiled using the "official" Gentoo ebuilds. Issue attributes: Status: New Owner: ---- Labels: Type-Defect Priority-Medium -- 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 0

Issue 220 in xmonad: Dmenu link is obsolete
by codesite-noreply＠google.com 20 Sep '08

20 Sep '08

Issue 220: Dmenu link is obsolete http://code.google.com/p/xmonad/issues/detail?id=220 Comment #1 by m...(a)twifkak.com: Samori, Thanks for the report. (You can also post to the mailing list or the IRC channel, but as this is a bug, this seems fine.) Link is now fixed in darcs (yes, the web page has a darcs repo), and will be fixed when we next do a push (soon). I think I'll leave the debian instructions out, as the other distros will then feel unloved, and that's really a job for dmenu's page. Issue attribute updates: Status: Fixed Labels: Documentation -- 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 0

Issue 220 in xmonad: Dmenu link is obsolete
by codesite-noreply＠google.com 20 Sep '08

20 Sep '08

Issue 220: Dmenu link is obsolete http://code.google.com/p/xmonad/issues/detail?id=220 New issue report by SamoriGorse: Hi all, As I can't find a way to contact you about this, I thought I'd file an issue, hope you don't mind :-) The intro page ( http://xmonad.org/intro.html ) provides an obsolete link to the Dmenu project page It links to : http://www.suckless.org/wiki/tools/xlib While the correct link is : http://www.suckless.org/programs/dmenu.html Also, debian-like distributions provide a package with dmenu sudo apt-get install dwm-tools would do. Keep up the good work :-) Issue attributes: Status: New Owner: ---- Labels: Type-Defect Priority-Medium -- 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 0

Issue 219 in xmonad: Strange error with ToggleStruts
by codesite-noreply＠google.com 18 Sep '08

18 Sep '08

Issue 219: Strange error with ToggleStruts http://code.google.com/p/xmonad/issues/detail?id=219 Comment #1 by SpencerJanssen: Not an xmonad bug. This is fixed in the darcs version of xmobar. Issue attribute updates: Status: Invalid -- 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 0

Issue 219 in xmonad: Strange error with ToggleStruts
by codesite-noreply＠google.com 18 Sep '08

18 Sep '08

Issue 219: Strange error with ToggleStruts http://code.google.com/p/xmonad/issues/detail?id=219 New issue report by deniz.a.m.dogan: What steps will reproduce the problem? 1. Have an xmobar instance running at the top of the screen (opened with spawnPipe from xmonad.hs). 2. Move to an empty workspace. 3. Open a terminal (in my case urxvtc). 4. Reload the xmonad configuration. 5. Do "sendMessage ToggleStruts". What is the expected output? The terminal takes up the full screen space, moving "over" the top xmobar. What do you see instead? The terminal moves "under" the xmobar. What version of the product are you using? On what operating system? The darcs version. Please provide any additional information below. If this error is due to a module from XMonadContrib, please tag this issue with 'Component-Contrib' below. Attachments: xmonad.hs 5.8 KB Issue attributes: Status: New Owner: ---- Labels: Type-Defect Priority-Medium -- 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 0

Re: [xmonad] terminal that can handle being resized?
by Matt Brown 18 Sep '08

18 Sep '08

sorry all; gmail's reply is not including the list for some reason. On Thu, Sep 18, 2008 at 10:16 AM, Matt Brown <deadguysfrom(a)gmail.com> wrote: > I've just discovered that rxvt-unicode handles resizing perfectly > under gnome's default WM (in hardy), but not in xmonad. strange, > because gnome-terminal resizes the same in both. > > On Thu, Sep 18, 2008 at 12:57 AM, Andreas Niederl <rico32(a)gmx.net> wrote: >> Hi, >> >> Matt Brown wrote: >>> I'm using one of the standard layouts, where one window is bigger than >>> all the others, which is great, except my terminal emulator (xterm, >>> tried rxvt too) doesn't handle being resized very well. It starts >>> wrapping at the new width (also great). My problem is that when a >>> window starts out big, then gets shrunk and restored to its original >>> size, all the old lines are truncated at the small width. the rest of >>> the window is blank. is there a terminal that can handle being >>> resized better, or a config option for either of these? or is there a >>> way I can get xmonad to ask the window to redraw itself? >> >> I'm also having this problem and after some stracing I'm pretty sure >> that I'm experiencing a race condition in the Linux kernel between the >> terminal size ioctls. >> >> According to a Debian bugreport [1] mentioned on the rxvt-unicode list >> [2] this was introduced in 2.6.26rc1 and resolved in 2.6.27rc1. >> >> >> Regards, >> Andi >> >> [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=483564 >> [2] http://lists.schmorp.de/pipermail/rxvt-unicode/2008q3/000688.html >> >

1 0