GNOME Bugzilla – Bug 457984
Another GTK+ tooltip positioning problem (bottom of the screen)
Last modified: 2007-07-23 13:32:14 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).
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 ***
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.
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.
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.
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.
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.
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?