GNOME Bugzilla – Bug 516130
gtktooltip calls query function too soon
Last modified: 2017-07-30 11:26:34 UTC
i wrote a query function and enabled has-tooltip on a gtkwidget. merely moving the mouse pointer across the window causes my query function to be called many times (even though i never stopped the mouse long enough to cause a tooltip to appear) the query function should probably only be called once the mouse has been still long enough for a tooltip to actually be displayed.
It seems like the query-tooltip signal is emitted on motion-notify, enter-notify, leave-notify and scroll events and when it is time to show the tooltip. Which is not at all what the documentation says: "Emitted when the "gtk-tooltip-timeout" has expired with the cursor hovering "above" widget". The signal is not emitted unless the has-tooltip property is TRUE. But in the description of the tooltip API here http://lists.zerezo.com/gtk-devel/msg02385.html it is said that "once gtk is in tooltip mode, ::query_tooltip() is simply emitted as the pointer moves." So either the documentation is wrong or the implementation.
I agree that the code can be reworked to delay the actual queries. What you are seeing right now is probably this: 1st motion-event: no tooltip exists, one is created (no query here). 2nd motion-event: tooltip exists, via query we check whether to renew the popup timeout or terminate it. We can probably opt for always renewing the timeout and deciding in the popup timeout handler (if the tooltip is not visible yet). Also there are plans to limit the amount of calls to the query handler by doing some kind of throttling, a few people have also complained about superfluous calls to their query handlers.
I ran into this problem as well. I tried to reduce the traffic by changing the tooltip text at most only once every 10 seconds, but found that the tooltip would then be empty. So I created my text and saved it only once every ten seconds, but set the tooltip text every single time the callback was called. This call back would be much more efficient if it was only called after the timeout the way it is documented.
This issue is still not resolved.
This seems to be duplicated in bug #574941 and bug #580090, and causes problems in various applications, see bug #645284, bug #581311 and bug #636615. It seems that it is not correct for gtk_tooltip_trigger_tooltip_query() to just create a fake mouse move event, as a real mouse move event should reset the timer, while a tooltip_query() should do all the rest that is done in _gtk_tooltip_handle_event, but not reset the timer if it is already running.
I have just tested the attached bug, and it fixes the problem described in bug #636615 for me.
Created attachment 201321 [details] [review] query_tooltip should not reset the timer
Review of attachment 201321 [details] [review]: Just a couple of formal comments while you wait for review of a gtk maintainer... Also if possible, please attach a patch with git format-patch that includes the commit message with the rationale of the change. ::: gtk+3.0-3.0.12.orig/gtk/gtktooltip.c @@ +1507,3 @@ + +void +_gtk_tooltip_handle_event_real (GdkEvent *event, gboolean may_reset) This can be a static function that does not need to go in the .h file, just define it before _gtk_tooltip_handle_event @@ +1618,3 @@ if (hide_tooltip) gtk_tooltip_hide_tooltip (current_tooltip); else "else if" on the same line
Thanks for the hints. The gtk-git-repo is so large that I aborted the pull and based my change on the debian package... but I’ll download it again, recreate the patch and make the _real function static. This has also the advantage that I’ll likely appear as the Author of the patch in the gtk repo, which does not always happen with free-form patch files :-)
Created attachment 201737 [details] [review] Redone the patch with git.
I’m cleaning out my home directory and found a git repo with a path that did not make it upstream yet, so I’m checking back: Did anybody review the patch yet?
I should add, just for reference, that the bug is still present in gtk 3.2.3.
Created attachment 213141 [details] [review] Rebased. I just rebased the patch to current master, hoping it will eventually get applied.
By now, the bug #636615, which I assumed was caused by this, is closed, and I also cannot reproduce the problem described here any more. Guess this was fixed by something else and can be closed.
Closing as OBSOLETE for comment #14. Feel free to reopen if this proves to still be an issue.
I don't know in which version it's supposed to be fixed, but I'm using GTK 3.6.1, and query-tooltip is still call on every movement instead of 500ms after the last movement.
*** Bug 574941 has been marked as a duplicate of this bug. ***
*** Bug 580090 has been marked as a duplicate of this bug. ***