After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 457984 - Another GTK+ tooltip positioning problem (bottom of the screen)
Another GTK+ tooltip positioning problem (bottom of the screen)
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Widget: Other
2.11.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2007-07-18 14:41 UTC by Hans de Goede
Modified: 2007-07-23 13:32 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Hans de Goede 2007-07-18 14:41:39 UTC
I've updated my system to the latest Fedora development version yesterday, which includes gnome-panel 2.19.5 with exhibits this problem:

To reproduce:
-add a clock applet to your bottom panel
-set it to only display the time, not the date
-hold cursor over clock and wait

Expected results:
-tooltip with its bottom located above the panel / clock showing date

Actual result:
-tooltip with its bottom aligned with the bottom of the screen, covering the 
 mouse cursor, resulting in a fight to be on top between cursor and tooltip,
 which results in annoying flicker (and me not knowing the date).
Comment 1 Vincent Untz 2007-07-22 22:32:32 UTC
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find.


*** This bug has been marked as a duplicate of 408327 ***
Comment 2 Hans de Goede 2007-07-23 07:43:59 UTC
Erm, how is this a duplicate of 408327, 408327 is about adding new GTK API to help setting the tooltip location. This is a regression in gnome-panel-2.19.5 compared to gnome-panel-2.18.x, I seriously doubt that adding new API to GTK is going to fix this, at the minimum gnome-panel needs to use the new API, although I don't see why as this worked perfect before.

Also I've noticed that it is not just the clock-applet tooltip, if you have a window with a long window title, like for example the firefox window when the tab with this bug is selected, and that window is on the left of the "taskbar" and you hover your mouse over it the same happens.

This leads me to the conclusion that this happens whenever the tooltip is so wide that part of it goes over the right side of the screen when positioned normally. In this scenario for some reason the y coordinate of the bottom of the tooltip gets set to the bottom of the panel instead of to the top of the panel (with a bottom panel)

Notice that only the taskbar, launchers and the clock applet (of those I've tested) seem affected, the tooltips of the speaker icon and cpu speed applets are fine, even when the applets are put fully right on the panel.

This confirms to me that this is not a dup of 408327, as if this were a gtk issue, then all applets should be affected, re-opening.
Comment 3 Vincent Untz 2007-07-23 11:12:10 UTC
Hans: it really is a GTK+ bug, and it really is bug 408327. It's GTK+ which does all the work for the tooltip, and if the position is not okay, then it's a GTK+ bug.

I would have thought that bug 408327 was also about the bug you're describing (and not just about the new API), but I might be wrong.
Comment 4 Hans de Goede 2007-07-23 11:45:15 UTC
Vincent: I've been investigating this all morning and already had a long comment ready, I was waiting for a gtk2 build, here is what I've found sofar:

---

I've done some further experimenting, and I have the cause of this now. I've managed to make mixer-applet2 and cpufreq-applet exhibit the same behaviour, by rebuilding the latest gnome-applets release with these 2 patches applied:
http://svn.gnome.org/viewcvs/gnome-applets/trunk/cpufreq/src/cpufreq-applet.c?r1=10101&r2=10289&view=patch
http://svn.gnome.org/viewcvs/gnome-applets/trunk/mixer/applet.c?r1=10131&r2=10289&view=patch

Notice how in both cases the applet switched from using GtkTooltips to using gtk_widget_set_tooltip_text()

Doing some more svn searching has lead me to this patch:
http://svn.gnome.org/viewcvs/gnome-panel/trunk/applets/clock/clock.c?r1=10459&r2=10402&view=patch

First reverting the remove set_tooltip part from this patch:
http://svn.gnome.org/viewcvs/gnome-panel/trunk/applets/clock/clock.c?r1=10459&r2=10532&view=patch

And then completely reverting this patch:
http://svn.gnome.org/viewcvs/gnome-panel/trunk/applets/clock/clock.c?r1=10459&r2=10402&view=patch

Fixes the issue for the clock. However this does make it look like this is indeed a gtk2 bug.

---

Further svn digging has lead me to this patch:
http://svn.gnome.org/viewcvs/gtk%2B/trunk/gtk/gtktooltip.c?r1=18502&r2=18512&view=patch

I'm currently rebuilding the gtk2 rawhide srpm with this patch applied to confirm this fixes this.

Even if this fixes this, applet tooltips are now positioned right of the mouse cursor, where as they used to be popped up centered above the cursor, and for applets like launchers and other very non wide things, I find the right positioning wrong as the tooltip then is above something else then what its a tip for.
Comment 5 Hans de Goede 2007-07-23 12:31:28 UTC
Okay, I can confirm that this gtk patch:
http://svn.gnome.org/viewcvs/gtk%2B/trunk/gtk/gtktooltip.c?r1=18502&r2=18512&view=patch

Fixes the flickering but the positioning of the tooltips is really ugly. For example I only use a bottom panel with on the right a clock and even further right the mixer applet. If I now put my mouse cursor over the speaker to see the volume, the volume tooltip covers the clock and the notification area, which looks anything but pretty.

Another example, if you hover your mouse over a taskbar button for a window with a long title, and have the mouse almost of the bottom of the screen, then the tooltip will completely cover the button, thus you no longer see what you are going to click.

I know this sounds trivial, but I have been comparing the old and new ways of positioning the tooltips and for panel applets the old way is far superior.

When upgrading to gtk2-2.11.6 instead of 2.11.5 + the above patch, the postioning now is even ugly for the applets still using GtkTooltips instead of gtk_widget_set_tooltip_text(), so appearantly GtkTooltips was changed to use the same new ugly postioning, although this is consistent I would rather have seen things be done the other way around.

Comment 6 Matthias Clasen 2007-07-23 13:23:30 UTC
Sorry to hear that you invested a lot of time into this, Hans.

I have fixed the flickering problem last week before doing the 2.11.6 release.
I just couldn't get fedora builds done from Birmingham. I'll push 2.11.6 into
rawhide ASAP, now that I'm back.
Comment 7 Hans de Goede 2007-07-23 13:32:14 UTC
Matthias: gtk2 currently won't build under rawhide because of issues with gtkcupsutils.c, should be easy to fix.

I agree that this bug (flickering) is fixed now, but I _really_ dislike the way tooltips are being placed now, see comment #5. Should I file a new bug for this, or will that just be closed wontfix?