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

[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



-- 
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