<m8t> 08:58:10> +ongardie: sometimes the tooltip for datetime appears in the top left corner of the display, while my panel is at the bottom <m8t> 09:07:41> +ongardie: and fwiw, my panel is auto hidden, dunno if that is important I was able to reproduce with a top panel that is not auto hidden. I keep my datetime plugin towards the right side of the screen, and the tooltip sometimes appears near the top-left corner (at about (20,20)).
(In reply to comment #0) > <m8t> 08:58:10> +ongardie: sometimes the tooltip for datetime appears in the > top left corner of the display, while my panel is at the bottom > <m8t> 09:07:41> +ongardie: and fwiw, my panel is auto hidden, dunno if that is > important > > I was able to reproduce with a top panel that is not auto hidden. I keep my > datetime plugin towards the right side of the screen, and the tooltip sometimes > appears near the top-left corner (at about (20,20)). Confirming that the tooltip sometimes appears near the upper left corner instead of over the plugin. This happens when the plugin is in a vertical panel on the right side or in a horizontal panel at the bottom. Neither of my panels auto-hides.
(In reply to comment #1) > Confirming that the tooltip sometimes appears near the upper left corner > instead of over the plugin. This occurs regardless of whether the panel is configured to display "Date only" or "Time only". It also occurs regardless of whether the time format includes seconds or not.
I believe this is reproducible: Configure the panel to display "Date only" or "Time only". Close the properties dialog. Left click on the datetime plugin and do not move the cursor. The calendar appears and the tooltip appears in the upper left corner.
This appears to be a gtk2 bug. I have reproduced it in a test program and submitted a bug here: http://bugzilla.gnome.org/show_bug.cgi?id=538439
Regardless of whether it's a bug in GTK, we'll need a workaround.
(In reply to comment #5) > Regardless of whether it's a bug in GTK, we'll need a workaround. OK, you motivated me to try to find one. :-) This one seems to work in my test program (will try it in the plugin later). If the timeouts are global to the process, this would affect tooltips throughout the panel, so that could be a drawback. Documentation is here: http://library.gnome.org/devel/gtk/stable/GtkSettings.html --- helloworld2.c 2008/06/18 22:15:01 1.2 +++ helloworld2.c 2008/06/18 23:49:26 @@ -34,6 +34,10 @@ static gboolean query_tooltip(GtkWidget sprintf(str, "%d", n); gtk_tooltip_set_text(tooltip, str); + if (x < 0 && y < 0) { + return FALSE; + } + return TRUE; } @@ -43,6 +47,14 @@ static gboolean tooltip_timer(GtkWidget return TRUE; } +static void set_tooltip_timeouts() +{ + GtkSettings* sp = gtk_settings_get_default(); + gtk_settings_set_long_property(sp, "gtk-tooltip-browse-mode-timeout", 0, "foo"); + gtk_settings_set_long_property(sp, "gtk-tooltip-browse-timeout", 0, "foo"); + gtk_settings_set_long_property(sp, "gtk-tooltip-timeout", 0, "foo"); +} + int main( int argc, char *argv[] ) { @@ -92,6 +104,7 @@ int main( int argc, /* Always remember this step, this tells GTK that our preparation for * this button is complete, and it can now be displayed. */ + set_tooltip_timeouts(); gtk_widget_set_has_tooltip(button, TRUE); g_signal_connect(button, "query-tooltip", G_CALLBACK(query_tooltip), NULL); g_timeout_add(1000, (GSourceFunc) tooltip_timer, button);
Created attachment 1702 workaround for this bug Workaround for this bug. Patch is against trunk rev. 4984. Testing was done with gtk2 and glib2 from the Fedora rawhide repo. gtk2-2.13.3-1.fc10.i386 glib2-2.17.2-2.fc10.i386 AFAICT, both the tests for negative coordinates and the setting of the tooltip timeouts to zero are needed. The complications come from having to restore the default tooltip timeouts when the cursor leaves the button widget. Not doing this causes all the plugins in the panel to inherit the zero timeouts. Although I spent a lot of time on this, ISTM that it would be better to wait for feedback from the GTK developers on the bug I submitted to them before doing anything further with this patch.
I played with this issue for quite a while this afternoon...it's not friendly. That's a nice hack you've done in Attachment #1702 . I'm not very comfortable with committing it either, though, since I don't really understand the problem or how this gets around it. Based on my previous experience, bugs against GTK move *very* slowly. Maybe the next stable datetime release (which I still would like to get out soon!) should just not try to update the tooltip in an intelligent way. Just make the user move the mouse a bit to get an update, like it used to be.
Created attachment 1703 simplified partial workaround This is a simplified, partial workaround. It suppresses the tooltip in the upper left corner but does not alter the tooltip timeouts. The advantages are that the tooltip is not displayed in an unexpected location and the plugin should "just work" if a new GTK is released that fixes the underlying problem (I'm assuming that negative coordinates are a manifestation of the bug, so this patch will still work when negative coords are no longer passed to the "query-tooltip" handler.) The drawback is that the tooltip is not reliably displayed (setting the tooltip timeouts to zero, as in the previous patch, seems to ensure the tooltip is reliably displayed). Sometimes the tooltip is not displayed after a few seconds and no amount of cursor-wiggling over the button will produce a tooltip. The tooltip will appear if the cursor is moved off the button for about two seconds and then back on. This sometimes happens with other tooltips (e.g. for launchers) too. Further, if the tooltip is not displayed over the datetime button and the cursor is moved to an adjacent launcher, sometimes the launcher tooltip will appear in the upper left corner.
(In reply to comment #8) ... > should > just not try to update the tooltip in an intelligent way. Just make the user > move the mouse a bit to get an update, like it used to be. I would prefer to not have the tooltip feature if the date/time displayed in the tooltip is not accurately updated in real time. Since the previous release did not have tooltips, not including them would not be a regression. Tooltips could be regarded as a future enhancement. The code could be included, however, but disabled with something like this: /* to build with tooltips enabled change the 0 to a 1 */ #define USE_GTK_TOOLTIP_API 0 && GTK_CHECK_VERSION(2,12,0)
In reply to Comment #10: OK, that's what I've done for v0.6...just less professionally :) #define I_CAN_HAS_BUGGY_TULTIPZ 0 #define USE_GTK_TOOLTIP_API (I_CAN_HAS_BUGGY_TULTIPZ && \ GTK_CHECK_VERSION(2,12,0))
After deleting my xsettings.xml all tooltips work fine again. I fail to see what is different unfortunately - but it works for me.
(In reply to comment #4) > This appears to be a gtk2 bug. > I have reproduced it in a test program and submitted a bug here: > http://bugzilla.gnome.org/show_bug.cgi?id=538439 Fixed with the release GTK+ 2.15.4.
Tooltips are now enabled on GTK versions >= 2.15.4 See svn r7881