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

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



On Thu, Feb 26, 2015 at 11:24 AM, adam vogt <vogt.adam at 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 at 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 at 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 at 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 at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/xmonad/attachments/20150226/dc6c0cb9/attachment-0001.html>