Bug 15793

*** Bug 15794 has been marked as a duplicate of this bug. ***

Created attachment 17469 [details] Implement tooltips

Comment on attachment 17469 [details] Implement tooltips + if (toolTip.isEmpty()) + g_object_set(G_OBJECT(m_webPage), "has-tooltip", FALSE, NULL); + else + gtk_widget_set_tooltip_text(GTK_WIDGET(m_webPage), toolTip.utf8().data()); Is it a problem that has-tooltip is never set to TRUE? + static GtkTooltips* tooltips; + if (!tooltips) + tooltips = gtk_tooltips_new(); You should be able to do this in one line, since this is C++ code: static GtkTooltips* tooltips = gtk_tooltips_new();

Comment on attachment 17469 [details] Implement tooltips The use of the new API is correct, so r+ for that half. The implementation for the old tooltip API was incorrect and displayed tooltips at wrong times, eg on the www.google.com search entry. Please attach an additional fix for this. Also, remember to include a ChangeLog entry. Thanks!

First half of the fix landed in r28000.

Christian, Can you also look into the tooltips that appear on the right side of http://planet.gnome.org/ ? The tooltip bubble always seems to stay in the same place when you move up and down.

Created attachment 17538 [details] Fix the tooltip being in stuck at one place when hovering on consecutive links This patch fixes the situation when tooltips get stuck at one location when hovering on links with title attribute consecutively (e.g., planet.gnome.org sidebar feed list).

Do we really need to construct a whole new GtkWindow instance every time the tooltip text changes? I'm wondering why we can't get the built-in tooltip API to work the way we want and have to resort to creating our own window in the first place.

(In reply to comment #8) > Do we really need to construct a whole new GtkWindow instance every time the > tooltip text changes? I tried the single GtkWindow instance but it exhibited the same issue we are having (i.e., same behaviour as current implementation). > > I'm wondering why we can't get the built-in tooltip API to work the way we want > and have to resort to creating our own window in the first place. I must admit that my patch is a band-aid as I can't seem to find a better way using the existing (2.12) tooltips API to fix the issue. It seems that the only way to interact with the tooltip properly is to connect to the GtkWidget::query-tooltip signal as per documentation of GtkTooltip. But sending query-tooltip seems to duplicate functionality with ChromeClient::setToolTip (in terms of saying "show me a tooltip"), at least AFAIC. I hope that clears things a bit.

Comment on attachment 17469 [details] Implement tooltips Patch already landed, but the bug report needs to remain open. Removing r+ flag to clear the commit queue.

Comment on attachment 17538 [details] Fix the tooltip being in stuck at one place when hovering on consecutive links Kris (author of the new GtkTooltip API) suggested that this workaround shouldn't be necessary. r- based on this, though we might have to re-visit it if we can't find an alternative. One suggestion was to usegtk_tooltip_set_tip_area() but that requires that we have knowledge of existing tooltip areas, and the area has to be rectangular, neither of which is always true. The drawing area example in testtooltips might be a source of inspiration apparently. Jan, could you coordinate this effort with the GTK+ team? If it doesn't work out, we'll have to look at the hacks again. Thanks!

Created attachment 28648 [details] my own proposed work-around

Created attachment 28694 [details] my own proposed workaround Addressed comments by zecke on IRC: basically take the GdkDisplay from the toplevel, if available, and do our thing before emitting the hovering-link signal.

Comment on attachment 28694 [details] my own proposed workaround afterwards in which way? after we disable it and then query again (nitpicking at the language even when not qualified to do so...)? :)

Landed as r41971 with a fix for the nitpick hehe.