February 2008 - xmonad

Strange Thunar CPU idling phenomenon
by semdornus 23 Feb '08

23 Feb '08

I'm using XFCE's filemanager Thunar and am witnessing something strange when using xmonad. I would like to know if this is a problem with xmonad, or with my system. So if anyone uses Thunar could you please check if this happens? I tried this with my own config, but it happens with no config (=default one) as well. Steps to reproduce: 1. Start xmonad. 2. Start Thunar. 3. Move Thunar to a different workspace. 4. Observe Thunar's idling CPU state in htop or similar. On my PC it is now idling at 3-7%. 5. Switch to workspace where Thunar now is and change Thunar to a different directory. 6. Check CPU idling again. It is now 0% as expected. Strange thing is that just focusing Thunar on the second workspace isn't enough; you have to change the directory. I have no idea what causes this strange behavior. I tried other (tiling) window managers and they all start idling Thunar at 0% as expected. Anybody have an insight?

4 7

Issue 143 in xmonad: XEvent hook or similar needed
by codesite-noreply＠google.com 23 Feb '08

23 Feb '08

Issue 143: XEvent hook or similar needed http://code.google.com/p/xmonad/issues/detail?id=143 Comment #7 by andrea.rossato: ;-) -- 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 143 in xmonad: XEvent hook or similar needed
by codesite-noreply＠google.com 23 Feb '08

23 Feb '08

Issue 143: XEvent hook or similar needed http://code.google.com/p/xmonad/issues/detail?id=143 Comment #6 by nomeata: Nice. I'll be on a week's holyday now, but I'll see what's in the core by then :-) -- 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 143 in xmonad: XEvent hook or similar needed
by codesite-noreply＠google.com 23 Feb '08

23 Feb '08

Issue 143: XEvent hook or similar needed http://code.google.com/p/xmonad/issues/detail?id=143 Comment #5 by andrea.rossato: ok. this is what I have in mind. Attached you'll find a patch that adds XMonad.Hooks.Eventhook. This is a sample usage: main = xmonad ddefaultConfig {layoutHook = eventHook Test (avoidStruts myLayoutHook)} where myLayoutHook us your layout hook. To create an event handler see Test (it should be quite straightforward), but I0m here for any kind of explanation you may want. This patch requires the new runLayout method: http://www.haskell.org/pipermail/xmonad/2008-February/004846.html and probably my other patches to port the contrib library to it: http://www.haskell.org/pipermail/xmonad/2008-February/004859.html and maybe the one that fixes issue #111 too: http://www.haskell.org/pipermail/xmonad/2008-February/004860.html since I'm starting to feel a bit stupid to keep on writing code base on code I'm not even sure will be included in xmonad, this is my last patch. I'll take a break and will not spam anymore. cheers Attachments: eventHook.dpatch 38.9 KB -- 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 143 in xmonad: XEvent hook or similar needed
by codesite-noreply＠google.com 23 Feb '08

23 Feb '08

Issue 143: XEvent hook or similar needed http://code.google.com/p/xmonad/issues/detail?id=143 Comment #4 by andrea.rossato: (an emoticon to express the fact I was taking it as a nice challenge would have been appropriate... but sometimes you press a button to quickly) :-) -- 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 143 in xmonad: XEvent hook or similar needed
by codesite-noreply＠google.com 23 Feb '08

23 Feb '08

Issue 143: XEvent hook or similar needed http://code.google.com/p/xmonad/issues/detail?id=143 Comment #3 by andrea.rossato: Sounds like a challenge... be careful, I might be accepting it. -- 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 143 in xmonad: XEvent hook or similar needed
by codesite-noreply＠google.com 23 Feb '08

23 Feb '08

Issue 143: XEvent hook or similar needed http://code.google.com/p/xmonad/issues/detail?id=143 Comment #2 by nomeata: Sounds ok to me - as long as there is a simple wrapper I can use :-) I don't think I'll be writing the code you are describing there, but I'd gladly use it. -- 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 143 in xmonad: XEvent hook or similar needed
by codesite-noreply＠google.com 23 Feb '08

23 Feb '08

Issue 143: XEvent hook or similar needed http://code.google.com/p/xmonad/issues/detail?id=143 Comment #1 by andrea.rossato: After our conversation on IRC, I thought a bit more about this issue and this is the idea I'd like to play a bit with. If runLayout is going to be accepted (and I'm quite confident Spencer may not dislike the idea) - and if we solve issue #111 (and I did some steps in that direction) -, it would be possible to set up a layout modifier in a given workspace that would just intercept X events and handle them accordingly. This is the idea: we have a layout modifier like this data HandleEvent a = HandleEvent ToogleReceiver ... type ToogleReceiver = Bool this layout modifier would be using the modifyLayout method and, when called the first time, it would activate itself (or/and it could broadcast a message to deactivate the receivers on the other workspaces), and would start handling Events - Main.handle is going to broadcast them to all layouts, current, visible and hidden. This may sound ugly at the first sight. But if you think a bit, that could be a flexible solution: we could have an event handler attached to each workspace, and it could handle events globally, or on a workspace basis manner. Moreover, unlike an EventHook, which would be quite inflexible (the configuration is in a ReaderT monad), you could send messages to the HandleEvent modifier itself, to turn it on/off, or just change its behavior. Maybe I'm just wrong, but I think that before pushing for an event hook we should give this path a try. I would be really glad to give you all the help I can give to write such a layout modifier. Let me know. -- 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 111 in xmonad: Clicking on tab doesn't work if that screen doesn't have focus
by codesite-noreply＠google.com 23 Feb '08

23 Feb '08

Issue 111: Clicking on tab doesn't work if that screen doesn't have focus http://code.google.com/p/xmonad/issues/detail?id=111 Comment #10 by andrea.rossato: I'm adding the last version of my fix proposal here too. more info here: http://www.haskell.org/pipermail/xmonad/2008-February/004860.html Attachments: add_sendMessageWithNoRefresh_fixIssue#111.dpatch 12.8 KB -- 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: add sendMessageWithNoRefresh and have broadcastMessage...
by Andrea Rossato 23 Feb '08

23 Feb '08

Hi, this is a follow up of the discussion we had here: http://www.haskell.org/pipermail/xmonad/2008-February/004827.html and yesterday on the #xmonad channel. The description and the code seem quite clear but I'm here to give more details. After all this patch does nothing else but removing a bug in broadcastMessage: we cannot call handleMessage *within* runOnWorkspaces because this way we update the workspace record even when handleMessage return Nothing. "We upgrade" actually means "we downgrade" the workspace record, because we are actually removing all changes to the workspace done within handleMessage. As you see I didn't change the semantics of broadcastMessage: it is - and, after all our discussions, I think it must remain - a way of updating the layout record of a workspace without refreshing the screen, and *only* when handleMessage returns a Just ml. So now we have: 1. sendMessage to send a message to the current workspace and refresh the screen if handleMessage returns Just ml; 2. broadcastMessage: to send a message to every workspace and update the layout field of the workspace when handleMessage returns Just ml. Cheers, Andrea Sat Feb 23 14:07:02 CET 2008 Andrea Rossato <andrea.rossato(a)unibz.it> * add sendMessageWithNoRefresh and have broadcastMessage use it This patch: - moves broadcastMessage and restart from Core to Operations (to avoid circular imports); - in Operations introduces sendMessageWithNoRefresh and move updateLayout outside windows. - broadcastMessage now uses sendMessageWithNoRefresh to obey to this rules: 1. if handleMessage returns Nothing no action is taken; 2. if handleMessage returns a Just ml *only* the layout field of the workspace record will be updated.

1 0