June 2008 - xmonad - Haskell.org

haskell-x11 upload?
by Joachim Breitner 28 Jun '08

28 Jun '08

Hi Ian, I keep getting user reports about the missing Xinerama support in xmonad. Any chance that you can do an haskell-x11 update soon? If you want help with that (e.g. by preparing the package, or doing an NMU), please tell me so. Thanks, 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

Issue 197 in xmonad: Blocking on nextEvent stops other threads from running
by codesite-noreply＠google.com 28 Jun '08

28 Jun '08

Issue 197: Blocking on nextEvent stops other threads from running http://code.google.com/p/xmonad/issues/detail?id=197 Comment #1 by asampson: Please contact me on ats-xmonad(a)offog.org about this if necessary; it appears Google won't let me set my account to use a real email address. -- 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 197 in xmonad: Blocking on nextEvent stops other threads from running
by codesite-noreply＠google.com 28 Jun '08

28 Jun '08

Issue 197: Blocking on nextEvent stops other threads from running http://code.google.com/p/xmonad/issues/detail?id=197 New issue report by asampson: What steps will reproduce the problem? >From main, start another lightweight thread with forkIO that does something periodically (e.g. forever (putStrLn "hello, world" >> threadDelay 500000)). What is the expected output? What do you see instead? The new thread only gets a chance to run when xmonad receives an event, since xmonad spends most of its time blocked inside the Xlib bindings. What version of the product are you using? On what operating system? Darcs xmonad as of 2008-06-28, on Linux, with GHC 6.8.2. I've attached a patch that makes xmonad wait on the X file descriptor when there aren't any events waiting to be processed. Attachments: do-not-block-2.patch 4.0 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

darcs patch: instruct users to use exec to start xmonad from .xinitrc
by brianchina60221＠gmail.com 28 Jun '08

28 Jun '08

Thu Jun 26 04:18:00 CDT 2008 brian(a)lorf.org * instruct users to use exec to start xmonad from .xinitrc

5 5

darcs patch: XMonad/Prompt.hs: swap out nub for faste... (and 1 more)
by gwern0＠gmail.com 27 Jun '08

27 Jun '08

Fri Jun 27 12:26:04 EDT 2008 gwern0(a)gmail.com * XMonad/Prompt.hs: swap out nub for faster uniq Fri Jun 27 12:28:42 EDT 2008 gwern0(a)gmail.com * XMonad/Prompt.hs: add sortPopular function and use sortPopular gets used in historyCompletion. I reasoned that it makes sense for search engine input to match primarily on previous entries and not just prefixes.

1 0

darcs patch: allow function keys up to F24
by brianchina60221＠gmail.com 26 Jun '08

26 Jun '08

Wed Jun 25 23:05:16 CDT 2008 brian(a)lorf.org * allow function keys up to F24

2 1

patch: fix looping due to unnecessary window crossing events
by Klaus Weidner 24 Jun '08

24 Jun '08

[ resent, the patch was buried in an older discussion. Let me know in case you prefer filing a bug. ] This patch fixes a race condition reported by David Roundy (Subject: Re: [xmonad] darcs patch: quick hack to avoid infinite (but breakable) loop when...): > The isMouseFocused hack introduced a race condition where if you click on a > tab to select a window, and then move the mouse down before the new window > is selected, the focus will alternate between the previously-focused and > newly-focused windows in an infinite loop. This loop can be broken by > moving the mouse up to the tab area, but it's pretty unpleasant. This race > condition is easily triggered on my laptop (and presumably on any older > computer running bloated applications like firefox). What is happening is apparently: a) click on tab causes window B to be focused (with mouseFocused true) b) mouse moves down into old window A, queueing an enter event for A c) xmonad maps window B, appearing under the mouse pointer d) enter event for B gets queued e) xmonad handles enter event for A, causing it to be focused f) xmonad maps window A, appearing under the mouse pointer g) enter event for B gets queued ... goto (c) The change is to ignore crossing events when the pointer is not currently in the window being reported as entered, for example due to having left it already, or if the windows were reshuffled due to keyboard commands. -Klaus

4 3

Scratchpad should match on class not on title
by Dominik Bruhn 22 Jun '08

22 Jun '08

Hy, the scratchpad has a big problem: As soon as some console-applications (like mutt, mocp) change the title of the terminal xmonad looses the scratchpad and starts a new one. This is because XMonad tries to find the scratchpad using the title which is imho not a good idea for reasons mentioned above. I tried to change this by using "-name" instead of "-title" as parameter for the terminal. This also adds a new WM_CLASS to the window named like the parameter. This Class doesnt change if a application changes the title so xmonad could match on this. I tried both urxvt and xterm, they both behave the same way: if you supply "-name scratchpad" on the comandline a new WM_CLASS named "scratchpad" is added to the window. I tried to change it on my own by changing the commandline (this worked without a problem) and then exchange the "scratchpadQuery" with scratchpadQuery = className =? "scratchpad" This doesnt work, the managehook doesnt find the window, so something is wrong. As I got no haskell knowledge debugging is difficult, so perhaps somebody can help me. I checked the scratchpad-window using xprop and i DOES have the scratchpad-class, so the Query is somehow wrong. Who can help me? Thanks -- Dominik Bruhn mailto: dominik(a)dbruhn.de

4 4

Patch: Use threadWaitRead to avoid blocking in nextEvent in the main loop
by Adam Sampson 22 Jun '08

22 Jun '08

Hi, I've been playing around with Control.Concurrent lately, and ran into a problem with xmonad as it stands: it usually blocks inside XNextEvent() in the main loop, so the Haskell runtime system never gets a chance to run any other lightweight threads. The attached patch uses threadWaitRead to tell the runtime system to wait for the X file descriptor to become ready before calling XNextEvent. This works for me: I've now got a couple of forkIO threads happily updating my status bar periodically. I'm not entirely convinced it's correct, though. Is it possible for the X server to send more than one event in a single communication? If so, it would be necessary to call nextEvent to handle the subsequent events before the file descriptor becomes ready again (which'd be easy if there's a way to find out whether there are any events pending without blocking). Thanks, -- Adam Sampson <ats(a)offog.org> <http://offog.org/>

2 2

darcs patch: Export PerWorkspace to allow type signatures
by Malebria 20 Jun '08

20 Jun '08

Thu Jun 19 22:50:46 BRT 2008 Malebria <malebria(a)riseup.net> * Export PerWorkspace to allow type signatures

2 1