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 <al...@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.cla...@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
al...@redhat.com alexander.lars...@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!
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
