Conference bulova::decw_jan-89_to_nov-90

>    Whose responsibility is it to prevent widget A responding?  Do I have
>    to do something special, or is this a bug in either widget A or widget
>    B?

Widgets don't ever try to determine if they "should" be getting an event.
If the server sends it to them they will respond.  So that leaves you
with two alternatives:

1.  Figure out how to make the server not send the event

2.  Add "state" to your application and ignore the widget when it's
    on the bottom.

The behavior you are seeing sounds strange to me.  Events do propogate up
the window hierarchy, but I didn't think they would propogate to a
"sibling".

Leo

You didn't say what kind of widget you are using, but I'll assume it is
a user-defined widget.  I think you have a widget bug.

Widgets that are mapped override redirect (without an enclosing shell) must
specify, in their Realize proc, that they don't want uninteresting events
propagated.  Widgets that do use a shell don't seem to have to do this,
although I'm not sure why not.  This protects the



static void DoRealize(w, maskP, attributesP)
    VMenuWidget w;
    Mask *maskP;
    XSetWindowAttributes *attributesP;
{
	...
	/* If we already have a do_not_propagate_mask, then augment
 	 * it to avoid propagating ButtonPress events.  If there is
	 * no do_not_propagate mask yet specified, supply one. */

        if (*maskP & CWDontPropagate)
	    attributesP->do_not_propagate_mask |= ButtonPressMask;
        else {
	    *maskP |= CWDontPropagate;
	    attributesP->do_not_propagate_mask = ButtonPressMask;
	}
	...
}

    Re .2
    
    I've seen this with the "underneath widget" being an SVN widget, and
    the "obscuring widget" being a dialog box with some push-button
    children.  The event that gets to the SVN widget is an MB2 press, which
    I've used OverrideTranslations on the SVN widget to catch (to activate
    a pop-up menu).
    
    Is .2 pointing the finger at the dialog box for propagating the MB2
    event, or the SVN widget for accepting propagated events?
    
    John

>>    I've seen this with the "underneath widget" being an SVN widget, and
>>    the "obscuring widget" being a dialog box with some push-button
>>    children.  The event that gets to the SVN widget is an MB2 press, which
>>    I've used OverrideTranslations on the SVN widget to catch (to activate
>>    a pop-up menu).
>>    
>>    Is .2 pointing the finger at the dialog box for propagating the MB2
>>    event, or the SVN widget for accepting propagated events?

It sounds to me like the dialog box's shell widget is the guilty party.
Shell widgets should probably not allow button or pointer events to
propagate.

However I, too, echo Leo's comment.  I would have expected the event
to propagate to an ancestor rather to a distant cousin.  Also, I have
not been able to reproduce this behavior (although I haven't tried it
on an SVN widget, just on other applications that have popup menus).

Can you tell us more about the dialog box?  Is it from the same application?
Modal or modeless?

-steve-

>However I, too, echo Leo's comment.  I would have expected the event
>to propagate to an ancestor rather to a distant cousin. 
    
    The dialog box is the child of the SVN widget, so the event is being
    propagated to an ancestor.
    
>It sounds to me like the dialog box's shell widget is the guilty party.
>Shell widgets should probably not allow button or pointer events to
>propagate.
>..............
>Can you tell us more about the dialog box?  Is it from the same application?
>Modal or modeless?
    
    It's not a popup dialog box, so it doesn't have a shell (that's right,
    isn't it?).  .1 indicated that widgets without shells shouldn't
    propagate uninteresting events to their parents either, but that they
    have to make sure of this themselves (rather than relying on an
    enclosing shell to squelch the events).  Is this right?
    
    John

None of the XUI widgets set do_not_propogate.  However, a dialog box (by
default) DOES select for ButtonPress events, so MB2 should be delivered
to the dialog box.  Is there a MB2 "grab" in place?

Leo

Ok.

Since you've made it clear that the dialog box is a *child* of the 
SVN widget, that changes things.

First off, I didn't know that the SVN widget *supports* arbitrary children.
I assumed that it doesn't like "adopted" children (ones that weren't created
by SVN itself).  So, it sounds like you're not doing a supported thing to
begin with.  But I don't know much about SVN and I might be wrong here.
It doesn't really matter to the rest of the discussion.

If SVN did (does) support arbitrary children, and you are adding
your own popup (MB2) trapping to SVN, then it becomes your responsibility
to determine whether the part of SVN over which MB2 was pressed belongs
to the unobscured region or the region covered by the dialog box.  Since
you created the dialog box, you can tell where it is and how big it is,
and you can tell whether a given event (sent to the SVN widget) is over
the dialog box or not.  You have to do this in your MB2 event handler routine.
If the dialog box completely covers the SVN window, then it means that
your application must have logic to ignore MB2 events whenever the dialog
box is mapped.

The bottom line in this case is that the application would be responsible
for "filtering" the events.

***

However, I think that you probably don't really want the dialog box to be
a child of the SVN widget anyway.  Instead, it should be a sibling of the SVN
widget, stacked above the SVN widget.  This will look the same on the screen,
but unhandled events over the dialog box will not be propagated to the
SVN widget but instead to the parent of the SVN widget (which will probably
just ignore them as you want them to be).

So just don't use SVN as the parent of the dialog box.

Ok?

-steve-