On Thu, Jan 7, 2016 at 11:03 PM Carlos Garcia Campos <[email protected]> wrote:
> El jue, 07-01-2016 a las 15:24 +0000, Mario Sanchez Prada escribió: > > On 07/01/16 07:19, Carlos Garcia Campos wrote: > [...] > > I can see that would be a redefinition of the "event was handled by > > that > > handler or now" concept, but perhaps it's good enough for this > > purpose of > > not stopping the propagation of the event while not requiring > > synchrony? > > > > Beware, I might be saying something really silly, but I had to ask. > > > > > > For the record, this is a problem in an app we have as we need to > > > > handle the > > > > "motion-notify-event" signal from the webview's parent GtkWidget, > > > > which is > > > > not possible atm due to [1], and not sure a workaround would make > > > > sense. > > > > > > Are you using a widget derived from WebKitWebView and handling the > > > event using the default handler? Because if you connect with > > > g_signal_connect you should get the events, since in that case the > > > callback is called before the default handler (motion-notify-event > > > is > > > a G_SIGNAL_RUN_LAST). > > > > Yes, connecting to the WebView with g_signal_connect() is not the > > issue (I > > can do it and get those events without problems), but the fact that > > connecting to the same signal from the container widget (whose > > GdkWindow has > > the GDK_POINTER_MOTION_MASK mask set) does not get the callback > > called. > > > > That's the problem I'm trying to solve or workaround here, but from > > your > > words I'm not entirely sure there's a good solution at the level of > > WK, so > > perhaps we should start looking into dealing with the signal emission > > from > > the WebView itself instead, not sure if that's possible though. > > > > In any case, and regardless of this, I think it would be interesting > > to have > > the WebView widget behaving like a normal GtkWidget and not > > swallowing those > > events, so any info/advice on this would still be much appreciated. > > A normal widget propagates the events when not handled, and stop > propagation when handled. We assume we handle all the events, because > we don't know it in advance. The only solution I can think of is re- > injecting events once we know they hasn't been handled. Or maybe for > some kind of events like mouse move there's no problem at all in always > propagate them. > I think it makes a lot of sense, what you say above about always returning FALSE specifically for mouse move events. With a click, I can see why the WebView should swallow it; a click is always intended for one target. But with a mouse movement, the mouse pointer is _there_ in the new location whether a target reacts to it or not. So even if you are drawing on a <canvas>, for example, that handles the mouse move events, why shouldn't GTK be able to handle them as well? Regards, Philip
_______________________________________________ webkit-gtk mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-gtk
