Re: Review of wip/carlosg/event-delivery

[Alexander Larsson <alexl redhat com>]

On Wed, 2017-05-17 at 17:45 +0200, Carlos Garnacho wrote:
> Hej hej,
>
> On Wed, May 17, 2017 at 3:27 PM, Alexander Larsson <alexl redhat com>
> wrote:
> > On Wed, 2017-05-17 at 01:04 +0200, Carlos Garnacho wrote:
> > > Hey,
> > >
> > > On Tue, May 16, 2017 at 8:24 PM, Matthias Clasen
> > > <matthias clasen gmail com> wrote:
> > > > On Tue, May 16, 2017 at 1:25 PM, Carlos Garnacho <carlosg@gnome
> > > > .org
> > > > > wrote:
> > > > >
> > > > >
> > > > > >   - interactive overlay: buttons over entry get prelights
> > > > > > and
> > > > > > clicks
> > > > > >     instead of the entry stealing them
> > > > >
> > > > > Hmm, the demo however sets the overlay as passthrough?
> > > > > https://git.gnome.org/browse/gtk+/tree/demos/gtk-demo/overlay
> > > > > .c#n
> > > > > 60
> > > >
> > > >
> > > > There's two overlay. One is passthrough, the other isn't: the
> > > > "Numbers" are
> > > > supposed to be passthrough, while the entry is supposed to get
> > > > input.
> > >
> > > Not what I see in code :). AFAICS both the entry and the label
> > > are
> > > children of a vbox, which is the only, pass-through overlay. The
> > > inspector seems to confirm this hierarchy.
> > >
> > > And this means gtk3 is broken :/, as it's essentially the same
> > > thing
> > > there.
> >
> > The test was added especially to test the case of a generally
> > transparent/shaped overlay that had some non-transparent child
> > widget.
> >
> > It works, because the entry has a GdkWindow that is not pass
> > through.
> > From the gdk_window_set_pass_through docs:
> >
> >  Note that a window with @pass_through %TRUE can still have a
> > subwindow
> >  without pass through, so you can get events on a subset of a
> > window.
> >  And in that cases you would get the in-between related events such
> > as
> >  the pointer enter/leave events on its way to the destination
> > window.
> >
> > In general, pass-through is related to a particular window, not the
> > entire sub-hierarchy. This matches the css pointer-events: none
> > behaviour, and anything else would be far less useful.
>
> Hmm, I see, missed those bits. Which doesn't match too well to a
> non-GdkWindow/GdkEventMask based world... how do we express this
> selective pass-through across complex portions of a widget hierarchy?
> The best I can think of is making GtkOverlay implement ::pick, make
> it
> peek the deepmost widget of the picking operation, and check whether
> any widgets on the way up to the overlay child have event controllers
> attached, that seems the closest to non-passthrough child windows.

I think we have to make GdkWindow::passthrough a feature of GtkWidget
instead, and respect it in the default pick operation.

Its a bit more work for people to set passthrough on all the widgets,
but its at least possible.

Conceptually one could have passthrough be a tri-state, with FALSE,
TRUE and SAME-AS-PARENT. I guess this is what CSS does essentially,
where you set pointer-events to "inherit".

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl redhat com            alexander larsson gmail com 
He's an all-American native American Green Beret haunted by memories of 
'Nam. She's an artistic mute snake charmer from a family of eight older 
brothers. They fight crime!