[xmonad] darcs patch: Split out the X event get function from xmonad.

[Lally Singh]

Hello!

Please tell me what you think, of both the patch and the process I'm
sending this in-by. First time for both.

Thanks!

1 patch for repository http://code.haskell.org/xmonad:

Thu Feb 26 10:22:06 EST 2015 ***@gmail.com
* Split out the X event get function from xmonad.

This lets xmonad users specify their own functions that get the next X
event,
and consequently have access to the Display and run in xmonad's thread.
Useful
for providing such access to other threads.



New patches:

[Split out the X event get function from xmonad.
***@gmail.com**20150226152206
Ignore-this: de10517364b9c642552ff62ebb614d28

This lets xmonad users specify their own functions that get the next X
event,
and consequently have access to the Display and run in xmonad's thread.
Useful
for providing such access to other threads.

] {
hunk ./src/XMonad/Main.hs 49
-- The main entry point
--
xmonad :: (LayoutClass l Window, Read (l Window)) => XConfig l -> IO ()
-xmonad initxmc = do
+xmonad initxmc = xmonad' defaultEventGetter initxmc
+
+-- | Default X event getter.
+defaultEventGetter :: Display -> XEventPtr -> X Event
+defaultEventGetter _ = io . getEvent
+
+-- | Actual entry point, with a parameter for the X event getter. The
getter
+-- has access to the X event loop.
+xmonad' :: (LayoutClass l Window, Read (l Window)) => (Display ->
XEventPtr -> X Event) -> XConfig l -> IO ()
+xmonad' eventGetter initxmc = do
-- setup locale information from environment
setLocale LC_ALL Nothing
-- ignore SIGPIPE and SIGCHLD
hunk ./src/XMonad/Main.hs 158
userCode $ startupHook initxmc

-- main loop, for all you HOF/recursion fans out there.
- forever $ prehandle =<< io (nextEvent dpy e >> getEvent e)
+ forever $ prehandle =<< eventGetter dpy e

return ()
where
}

[adam vogt]

Hi Lally,

I think the way you're proposing a change is just fine.

Does your patch work properly for you? You left out a call to
nextEvent which xmonad currently does. I would have written:

defaultEventGetter :: XEventPtr -> X Event
defaultEventGetter evPtr = do
d <- asks display
io $ do
nextEvent d evPtr
getEvent evPtr

Secondly, I would have added eventGetter as a field in XConfig, since
it doesn't scale to have

xmonad
xmonad'
xmonad''

etc. functions.

Finally, do you have an example of something you can do with the
eventGetter that cannot be done with handleEventHook?


Regards,
Adam

Post by Lally Singh
Hello!
Please tell me what you think, of both the patch and the process I'm
sending this in-by. First time for both.
Thanks!
* Split out the X event get function from xmonad.
This lets xmonad users specify their own functions that get the next X
event,
and consequently have access to the Display and run in xmonad's thread.
Useful
for providing such access to other threads.
[Split out the X event get function from xmonad.
Ignore-this: de10517364b9c642552ff62ebb614d28
This lets xmonad users specify their own functions that get the next X
event,
and consequently have access to the Display and run in xmonad's thread.
Useful
for providing such access to other threads.
] {
hunk ./src/XMonad/Main.hs 49
-- The main entry point
--
xmonad :: (LayoutClass l Window, Read (l Window)) => XConfig l -> IO ()
-xmonad initxmc = do
+xmonad initxmc = xmonad' defaultEventGetter initxmc
+
+-- | Default X event getter.
+defaultEventGetter :: Display -> XEventPtr -> X Event
+defaultEventGetter _ = io . getEvent
+
+-- | Actual entry point, with a parameter for the X event getter. The
getter
+-- has access to the X event loop.
+xmonad' :: (LayoutClass l Window, Read (l Window)) => (Display -> XEventPtr
-> X Event) -> XConfig l -> IO ()
+xmonad' eventGetter initxmc = do
-- setup locale information from environment
setLocale LC_ALL Nothing
-- ignore SIGPIPE and SIGCHLD
hunk ./src/XMonad/Main.hs 158
userCode $ startupHook initxmc
-- main loop, for all you HOF/recursion fans out there.
- forever $ prehandle =<< io (nextEvent dpy e >> getEvent e)
+ forever $ prehandle =<< eventGetter dpy e
return ()
where
}
_______________________________________________
xmonad mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad

[Brandon Allbery]

Post by adam vogt
Finally, do you have an example of something you can do with the
eventGetter that cannot be done with handleEventHook?

One thing I've wanted is the ability to hook into GHC's I/O manager instead
of polling X11 directly. Currently, other threads will not run until xmonad
receives an X11 event, because it's blocked in the FFI instead of the I/O
manager monitoring the X11 socket. This also means you can't sensibly wait
on both a socket/pipe and X11 events.

(Doing the above right also implies that either we synthesize X11 events
for non-X11 events, or add an additional eventHook for them. The latter is
probably easier, since the former either needs to "steal" an event type
from X11 or a rather nonsensical patch to the X11 bindings to support a
non-X11 event as an "X11" event type.)

[Lally Singh]

Ah, that's what I get for trying to hastily port a larger set of changes by
hand. I'll re-make the patch with your excellent suggestions.

My event getter calls select(2) on both the display's FD and a pipe. The
pipe has a byte written when a queue has a closure on it, which the event
getter runs with the X state. <
https://github.com/lally/config/blob/xmonad-cairo/xmonad/Support/Launch.hs#L184>
Another thread runs a local webserver, with the hope to let other apps
pull JSON state descriptions of what windows are where (with some x
property tagging) to try and attach semantics to the windows.

As Brandon says, it's mostly about getting select(2) to wait on more than 1
fd at a time.

Post by adam vogt
Hi Lally,
I think the way you're proposing a change is just fine.
Does your patch work properly for you? You left out a call to
defaultEventGetter :: XEventPtr -> X Event
defaultEventGetter evPtr = do
d <- asks display
io $ do
nextEvent d evPtr
getEvent evPtr
Secondly, I would have added eventGetter as a field in XConfig, since
it doesn't scale to have
xmonad
xmonad'
xmonad''
etc. functions.
Finally, do you have an example of something you can do with the
eventGetter that cannot be done with handleEventHook?
Regards,
Adam

Post by Lally Singh
Hello!
Please tell me what you think, of both the patch and the process I'm
sending this in-by. First time for both.
Thanks!
* Split out the X event get function from xmonad.
This lets xmonad users specify their own functions that get the next X
event,
and consequently have access to the Display and run in xmonad's thread.
Useful
for providing such access to other threads.
[Split out the X event get function from xmonad.
Ignore-this: de10517364b9c642552ff62ebb614d28
This lets xmonad users specify their own functions that get the next X
event,
and consequently have access to the Display and run in xmonad's thread.
Useful
for providing such access to other threads.
] {
hunk ./src/XMonad/Main.hs 49
-- The main entry point
--
xmonad :: (LayoutClass l Window, Read (l Window)) => XConfig l -> IO ()
-xmonad initxmc = do
+xmonad initxmc = xmonad' defaultEventGetter initxmc
+
+-- | Default X event getter.
+defaultEventGetter :: Display -> XEventPtr -> X Event
+defaultEventGetter _ = io . getEvent
+
+-- | Actual entry point, with a parameter for the X event getter. The
getter
+-- has access to the X event loop.
+xmonad' :: (LayoutClass l Window, Read (l Window)) => (Display ->

XEventPtr

Post by Lally Singh
-> X Event) -> XConfig l -> IO ()
+xmonad' eventGetter initxmc = do
-- setup locale information from environment
setLocale LC_ALL Nothing
-- ignore SIGPIPE and SIGCHLD
hunk ./src/XMonad/Main.hs 158
userCode $ startupHook initxmc
-- main loop, for all you HOF/recursion fans out there.
- forever $ prehandle =<< io (nextEvent dpy e >> getEvent e)
+ forever $ prehandle =<< eventGetter dpy e
return ()
where
}
_______________________________________________
xmonad mailing list
http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad