🚀 go-pugleaf

linton@marktwain.rad.sgi.com (Mark Linton) writes:

>In article <ld6a9iINNae8@news.bbn.com>, jpalmucc@bbn.com (Jeff Palmucci) writes:
>|> bennett@mozart.redwood.com (Michael Bennett) writes:
>|> >  The Button, as an ActiveHandler,
>|> >grabs events while the cursor is within the Button.  It grabbed my
>|> >keystroke events and ignored them.  Shouldn't the Button somehow send
>|> >along keystrokes since it doesn't care about them?  
>|> 
>|> I ran into the same problem with a Drag around an ActiveHandler. As
>|> soon as the mouse enters the ActiveHandler extension, the
>|> ActiveHandler grabs all the events, including the middle button press
>|> that was meant to start the drag.
>|> 
>|> >And, possibly
>|> >related, why does Handle::event() now return a boolean?  What does it
>|> >mean?  Is this what the button event grabber should use to indicate
>|> >that it didn't handle the keystroke event so it can be dispatched to
>|> >someone who wants it?
>|> 
>|> It looks like the boolean is ignored. I'd like to know what future
>|> versions will do with it.
>|> 
>|> >Anyone know what I should be doing to accomplish this?
>|> 
>|> Yeah, anyone?

>I fixed a problem in beta3 that should fix the case where buttons
>eat keyboard events.  If the problem is still occuring, please send
>me an example program.

Your fix explicity checks for KeyPress events. The problem we are
having is that non KeyPress events are getting eaten by the
InputHandlers.

An InputHandler grabs events in two cases. One is when the pointer
enters the InputHandler's extension, and the other is when the mouse
is pressed inside the extension.

It grabs events to insure that it will not miss the pointer leaving
the extension, or the mouse button being released.

This means that other glyphs, that may also be interested in these
events, will never get them. The simplest example is when one
InputHandler is nested inside another. Only the outer InputHandler
will see any events.

What we need is a way to watch the event stream without disrupting it.
I have patched my local copy to support Event::watch and
Event::unwatch, in addition to Event::grab and Event::ungrab.

A watcher is like a grabber, except that after it processes the Event,
the Event is also processed by Event::handler (and any other watchers
that are registered on the display).

Since my InputHandler is based on watchers instead of grabbers, they
can see when to call InputHandler::release and ActiveHandler::leave
without grabbing events from other glyphs that may be interested in
them.

This means that I can nest my InputHandlers.

Jeff