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 <vogt.adam@gmail.com> 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 <lally.singh@gmail.com> 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
>