Re: Review of wip/carlosg/event-delivery

[Carlos Garnacho <carlosg gnome org>]

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.

Cheers,
  Carlos

> --
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>  Alexander Larsson                                            Red Hat, Inc
>        alexl redhat com            alexander larsson gmail com
> He's a shy Republican ex-con with a passion for fast cars. She's a
> wealthy wisecracking nun fleeing from a Satanic cult. They fight crime!