XEvent hook or similar needed

[GoogleCodeExporter]

Hi,

I’ve mentioned this a few times in the past, but I want this tracked here:

For proper EWMH support, I need a way to get XEvents (ClientMessage events
in particular) independent from the current workspace or layout, reliably,
and exactly once. This is logically equivalent to what we do to key events,
just that there is nothing the user needs to configure (besided enabling
the EWMH module).

I think the cleanest solution would be a new hook, similar to logHook, that
passes any received XEvent to interested modules.

Thanks,
Joachim

Original issue reported on code.google.com by nome...@gmail.com on 22 Feb 2008 at 6:29

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

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.

Original comment by nome...@gmail.com on 23 Feb 2008 at 5:36

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

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

Original comment by andrea.rossato@gmail.com on 23 Feb 2008 at 9:28

Attachments:

• eventHook.dpatch

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I know I promised not to send patches... and indeed I'm not sending this one... 
I'm
just attaching it here...;)

Since I like this idea I did some improvements and so I amended the previous 
patch:

1. now the modifier will activate itself on the first current workspace (and 
not on
the first one);

2. I added haddock documentation;

3. I changed the Test eventHook into EventHookExample that will log to stderr 
every
event, but will specifically handle a button event. To test, just click over the
decoration of a decorated layout.

Maybe some would like to play with it. This code requires my other patches I 
listed
above.

I'm on vacation now...:-)

Original comment by andrea.rossato@gmail.com on 24 Feb 2008 at 8:13

Attachments:

• eventHookImproved.dpatch

[GoogleCodeExporter]

Andrea's approach is novel, but it seems a bit complicated.  I think we just 
ought to
add support for this in the core.  The question is, what interface?  The 
simplest I
can imagine is "messageHook :: [SomeMessage -> X ()]" as a field in the user's
config.  Is this sufficient for EWMH?  Is it sufficient for other hooks?  (have 
we
even imagined any other uses for this hook?)

Original comment by SpencerJ...@gmail.com on 29 Feb 2008 at 9:14

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Part of the question is speed; if every event gets run through a list of such
handlers, it seems like the majority of the events will end up back in the 
hands of
Main's handle function. I don't know how frequently events arrive.

Maybe use pattern matching? Rename the existing handle to handle', the new 
handle
tries the user's messageHook (:: Event -> X Bool, pattern matching like handle 
but
indicating whether handle' should still process the event), and if the response 
is
False, try it with handle'. I'm not sure how pattern matching would compare
speed-wise with a list. It also enforces only one handler per event, which I 
think
might be desirable.

Whatever solution is settled on, I think it's desirable to have type -> X Bool, 
so
the user's message handlers can either eat the event, or leave it to be 
processed as
normal. That opens up the ability for extensions to observe events without 
consuming
them.

And as a use case other than EWMH: timers. The current Util.Timer module only 
works
for LayoutModifiers, because only they can handleMessage right now. Instead, 
this
module could just offer a handleTimer to use in messageHook, and then we have
general-purpose timers.

Original comment by Braden.S...@gmail.com on 29 Feb 2008 at 1:23

[GoogleCodeExporter]

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.

Original comment by andrea.rossato@gmail.com on 13 Mar 2008 at 12:03

Attachments:

• eventHook_patches.dpatch

[GoogleCodeExporter]

Well, I guess I can close this now that Andrea’s EventHook is in. 
Unfortunately, I
can’t (google code is somewhat restrictive it seems). Feel free to close it, 
dons.

Original comment by nome...@gmail.com on 19 Mar 2008 at 9:19

[GoogleCodeExporter]

Patch applied. Fixed to requestors satisfaction.

Original comment by don...@gmail.com on 19 Mar 2008 at 9:32

• Changed state: Fixed