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. On Thu, Feb 26, 2015 at 11:24 AM, adam vogt wrote:

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

On Thu, Feb 26, 2015 at 10:29 AM, Lally Singh wrote:

...

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 lally.singh@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. lally.singh@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 }

_______________________________________________ xmonad mailing list xmonad@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad