[xmonad] Issue 143 in xmonad: XEvent hook or similar needed

[Don Stewart]

Joachim, if you can revive this, and polish it up into something you can
use, please do.

-- Don

mail:
> Hi Andrea,
> 
> I just found some free time to try your patches, but it seems that your
> comments in the google bts were deleted. Was that a mistake? And where
> can I find your patches now? 
> 
> I also can’t find your repositories
> http://gorgias.mine.nu/repos/xmonad/
> http://gorgias.mine.nu/repos/xmonad-contrib/
> any more.
> 
> Greetings,
> Joachim
> 
> Am Donnerstag, den 13.03.2008, 05:03 -0700 schrieb
> codesite-noreply at google.com:
> > Issue 143: XEvent hook or similar needed
> > http://code.google.com/p/xmonad/issues/detail?id=143
> > 
> > Comment #11 by andrea.rossato:
> > Spencer: yes, it's a bit more complicated (not that much I believe),
> > still it could be done NOW - my runLayout approach has been pushed
> > (btw, you are still the project leader, are you? it would be scary if
> > this wouldn't be the case... but maybe you just changed you mind: I'd
> > be delighted of that...:-)
> > 
> > Anyway, nomeata could experiment with my event hook and see what is
> > the needed interface. After that Spencer could decide the core
> > implementation, if needed.
> > 
> > I remember we had, in a far past, discussed about an event hook. At
> > the time many ratpoisen users kept asking the possibility of sending
> > commands to the Window Manager from the command line (for scripting
> > purposes). I remember Spencer was contrary to adding hooks - an easy
> > solution when you run out of ideas. I took it as a sounded guideline
> > and I tried to follow it constantly.
> > 
> > My attempt was to increase the expressiveness of the layout class in
> > order to allow many hooks to be implemented in the layout hook: at
> > first I thought about the layout combinator class - at the time it
> > seemed to me the best solution - and then I came up with the runLayout
> > solution, which makes the combinator class useless and indeed allows
> > and event hook to be implemented as a layout.
> > 
> > Joachim: attached you'll find my refined event hook patch, and
> > ServerMode, the ratpoison command line interface, as an example. You
> > wrote that you need to intercept ClientMessage, and ServerMode does
> > exactly that (I think byorgey could even consider them for inclusion
> > in the contrib library now that runLayout has been adopted).
> > 
> > If you want to try to implement your EWMH stuff with this approach you
> > can contact me - either privately or on IRC - and I'll be delighted to
> > give you my help.
> > 
> > Braden: I think you do not have a clear understanding of xmonad
> > message handling. Messages are not consumed, they are just sent. There
> > are 2 way of sending a message:
> > 
> > 1. with sendMessage: the current workspace is taken from the XState,
> > its layout field is used as an argument of handelMessage and, if a new
> > layout is returned, the screen is refreshed and the workspace, with a
> > new layout field and with the updated stack field, is saved in the
> > XState.
> > 
> > 2. with broadcastMessage: in this case the layout field of every
> > workspace is updated without refreshing the screen. At the present
> > time broadcastMessage is badly broken (it always has been): see issue
> > #111. When handleMessage is called, the call may change the stack of
> > some workspace. But since broadcastMessage is run within
> > runOnWorkspaces, the workspace layout field is updated, but the stack
> > of the workspace is not updated. That is to say, the stack field of
> > the workspace before running handleMessage is used to save the XState
> > after updating the layout field (I've discussed many times this issue,
> > but no one seems to care).
> > 
> > Just try with ServerMode and see what happens when you send a command
> > that changes the stack of a workspace. You'll see the effect, but the
> > effect will not be saved.
> > 
> > This is obviously a general problem and a really bad and longstanding
> > bug in the xmonad core. Implementing an EventHook as the startupHook,
> > the logHook, the manageHook and many other hooks your imagination
> > could come up with could be a way of forgetting about issue #111. And
> > if you do not use decorated layouts you could even come to think that
> > issue #111 is just the fixed idea of a psychopathic wannarebe
> > developer who has nothing better to do.
> > 
> > But this is out of the scope of this feature request.
> > 
> > 
> > Attachments:
> > 	eventHook_patches.dpatch  55.8 KB
> > 
> > 
> 
> -- 
> Joachim "nomeata" Breitner
>   mail: mail at joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C
>   JID: nomeata at joachim-breitner.de | http://www.joachim-breitner.de/
>   Debian Developer: nomeata at debian.org



> _______________________________________________
> xmonad mailing list
> xmonad at haskell.org
> http://www.haskell.org/mailman/listinfo/xmonad