- xmonad - Haskell.org

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

darcs patch: Combo: updated to latest runLayout changes (and 5 more)
by Andrea Rossato 23 Feb '08

23 Feb '08

Hi, this is a new bundle with a corrected LayoutCombinators patch and the missing ToggleLayouts. Later today I'll also send something related to the message handling in order to summarize a discussion we had yesterday on IRC. andrea Fri Feb 22 18:59:24 CET 2008 Andrea Rossato <andrea.rossato(a)unibz.it> * Combo: updated to latest runLayout changes Fri Feb 22 18:59:54 CET 2008 Andrea Rossato <andrea.rossato(a)unibz.it> * PerWorkspace: reimplemented using runLayout This way we have a Xinerama safe PerWorkspace and the emptyLayout method for free. Sat Feb 23 08:55:31 CET 2008 Andrea Rossato <andrea.rossato(a)unibz.it> * PerWorksapce: use a safer False as default Sat Feb 23 08:56:10 CET 2008 Andrea Rossato <andrea.rossato(a)unibz.it> * LayoutModifier: reimplement ModifiedLayout using runLayout and more - change modifyLayout type to get the Workspace - updated ResizeScreen and ManageDocks accordingly. Sat Feb 23 09:09:58 CET 2008 Andrea Rossato <andrea.rossato(a)unibz.it> * LayoutCombinators: NewSelect reimplemented with runLayout Sat Feb 23 09:15:53 CET 2008 Andrea Rossato <andrea.rossato(a)unibz.it> * ToggleLayouts: reimplemented with runLayout

1 0

darcs patch: Combo: updated to latest runLayout changes (and 4 more)
by Andrea Rossato 23 Feb '08

23 Feb '08

Hi, this is a follow up of my yestarday proposal of the new runLayout method. These are all the needed updates to the contrib library to work with the new method... (while writing this sentence it came to my mind that ToggleLayouts is missing, and I'm sending this with darcs - which means I'll send that patch later, since I think I cannot stop the sending process anymore...;). Cheers, Andrea Fri Feb 22 18:59:24 CET 2008 Andrea Rossato <andrea.rossato(a)unibz.it> * Combo: updated to latest runLayout changes Fri Feb 22 18:59:54 CET 2008 Andrea Rossato <andrea.rossato(a)unibz.it> * PerWorkspace: reimplemented using runLayout This way we have a Xinerama safe PerWorkspace and the emptyLayout method for free. Sat Feb 23 08:53:28 CET 2008 Andrea Rossato <andrea.rossato(a)unibz.it> * LayoutCombinators: NewSelect reimplemented with runLayout Sat Feb 23 08:55:31 CET 2008 Andrea Rossato <andrea.rossato(a)unibz.it> * PerWorksapce: use a safer False as default Sat Feb 23 08:56:10 CET 2008 Andrea Rossato <andrea.rossato(a)unibz.it> * LayoutModifier: reimplement ModifiedLayout using runLayout and more - change modifyLayout type to get the Workspace - updated ResizeScreen and ManageDocks accordingly.

1 1

darcs patch: update LOC claim in man page
by gwern0＠gmail.com 23 Feb '08

23 Feb '08

Fri Feb 15 16:14:20 EST 2008 gwern0(a)gmail.com * update LOC claim in man page

3 2

Re: [xmonad] my proposal for a Xinerama safe PerWorkspace
by Brent Yorgey 22 Feb '08

22 Feb '08

oops, forgot to cc: the list! On Fri, Feb 22, 2008 at 1:27 PM, Andrea Rossato <andrea.rossato(a)unibz.it> wrote: > On Fri, Feb 22, 2008 at 07:12:31PM +0100, Andrea Rossato wrote: > > Hi, > > > > this is my proposal for a Xinerama safe PerWorkspace. > Hm, this does not work for me. All workspaces have the first layout and never switch to the other one, even after opening new windows, hitting mod-space, mod-shift-space, etc. In general, however (assuming it could be made to work) I like this idea: moving runLayout into the LayoutClass, with a slightly different signature (so that it receives the whole Workspace rather than just the layout to use) seems like a fairly elegant solution. The major difference between this and my proposed startupHook solution (see here<http://article.gmane.org/gmane.comp.lang.haskell.xmonad/4392/>and here <http://article.gmane.org/gmane.comp.lang.haskell.xmonad/4389/>) is that this solution, like the previous incarnation of PerWorkspace, cannot figure out which workspace to use until runLayout actually gets called. In and of itself this is not necessarily a big problem (although I find it slightly annoying). However, because of this I must disagree with your decision to change Maybe Bool to Bool in the PerWorkspace data structure. Before runLayout is called, the only reasonable thing to do is show a generic description (such as "PerWorkspace") and pass all messages on to both underlying layouts, rather than use the wrong layout on some workspaces. At any rate, even if Bool is retained rather than Maybe Bool, the sensible default would be False rather than True, since this would select the 'default' layout by default, instead of the workspace-specific layout. cheers, -Brent

2 5