|Summary:||[GTK] tooltip position doesn't update when hovering consecutive links|
|Product:||WebKit||Reporter:||Salvatore De Paolis <iwkse>|
|Severity:||Enhancement||CC:||alp, christian, gns, grahamperrin, jakub.rusinek, jmalonzo, kris|
|Version:||523.x (Safari 3)|
Description Salvatore De Paolis 2007-11-02 07:38:14 PDT
While loading a picture, if it contains a title tag, this isn't showed in a tooltip.
Comment 1 Matt Lilek 2007-11-02 08:04:21 PDT
*** Bug 15794 has been marked as a duplicate of this bug. ***
Comment 2 Christian Dywan 2007-11-23 12:40:02 PST
Created attachment 17469 [details] Implement tooltips
Comment 3 Adam Roben (:aroben) 2007-11-23 12:53:22 PST
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 4 Alp Toker 2007-11-24 13:50:47 PST
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!
Comment 6 Alp Toker 2007-11-24 14:10:34 PST
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.
Comment 7 Jan Alonzo 2007-11-26 14:24:21 PST
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).
Comment 8 Alp Toker 2007-11-26 15:36:24 PST
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.
Comment 9 Jan Alonzo 2007-11-26 19:32:54 PST
(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 10 Alp Toker 2007-11-27 22:10:31 PST
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 11 Alp Toker 2007-12-04 09:48:43 PST
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!
Comment 12 Gustavo Noronha (kov) 2009-03-16 09:10:41 PDT
Created attachment 28648 [details] my own proposed work-around
Comment 13 Gustavo Noronha (kov) 2009-03-17 11:20:11 PDT
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 14 Holger Freyther 2009-03-25 00:11:24 PDT
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...)? :)