Re: Review of wip/carlosg/event-delivery
- Date: Wed, 17 May 2017 15:27:33 +0200
- From: Alexander Larsson <alexl@xxxxxxxxxx>
- Subject: Re: Review of wip/carlosg/event-delivery
On Wed, 2017-05-17 at 01:04 +0200, Carlos Garnacho wrote:
> On Tue, May 16, 2017 at 8:24 PM, Matthias Clasen
> <matthias.clasen@xxxxxxxxx> wrote:
> > On Tue, May 16, 2017 at 1:25 PM, Carlos Garnacho <carlosg@xxxxxxxxx
> > > 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
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.
Alexander Larsson Red Hat, Inc
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!
gtk-devel-list mailing list