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 50619 - Rework tooltips
Rework tooltips
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: Other
1.3.x
Other All
: Normal enhancement
: Big API
Assigned To: gtk-bugs
gtk-bugs
: 51035 86332 (view as bug list)
Depends on:
Blocks: 63019 65490 71413 73257 75961 80980
 
 
Reported: 2001-02-06 19:38 UTC by Jon Kåre Hellan
Modified: 2015-11-14 16:46 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement


Attachments
bugzilla garbled the patch I entered in the description field, so here I try again (5.54 KB, patch)
2001-02-06 19:40 UTC, Jon Kåre Hellan
none Details | Review
allocates GtkTooltipsData using memchunks (from TODO) (2.74 KB, patch)
2002-02-24 07:23 UTC, Zack Rusin
none Details | Review

Description Jon Kåre Hellan 2001-02-06 19:38:15 UTC
In May 2000, I proposed a patch to improve tooltip browsing. It eliminates
the wait before tooltips pop up if you're just moving the mouse along the
toolbar. As soon as you do anything but moving the mouse, normal behaviour
returns - there's a timeout before tooltip pops up. Normal behaviour also
returns a certain time after the last tooltip pops down.

Tim Janik responded with some comments. Here is a version with his
suggested changes, first submitted June 2000. I've updated it so it is
against CVS Feb 6 2000.

Tim Janik <timj@gtk.org> wrote:
> the way i read your patch, you stay in sticky mode even if you perform
> normal actions like pressing a button or a key.
> there, you should actually leave sticky mode, i.e. the tooltips only popup
> with a (shorter) sticky delay if we just recently showed a tooltip and
> only processed enter/leave events meanwhile.
I've done as suggested. It won't catch button or key presses in
widgets which do not use this tooltip, but that's not much of a
problem in practice.

> rather than comparing the timestamp against the sticky delay, i'd probably
> use it to constrain the code path (in the above patch) for usage of the
> sticky_delay to a certain threshold, say 3 seconds (so when a tooltip popped
> down, and the next one is supposed to popup with sticky_delay, that'll only
> happen within the next three seconds).

OK. I've hardcoded 1 s. STICKY_REVERT_DELAY. I hate to hardcode   
things, but it isn't very useful to tune.

Index: ChangeLog
===================================================================
RCS file: /cvs/gnome/gtk+/ChangeLog,v
retrieving revision 1.1707
diff -u -r1.1707 ChangeLog
--- ChangeLog	2001/02/06 03:08:31	1.1707
+++ ChangeLog	2001/02/06 19:27:19
@@ -1,3 +1,25 @@
+2001-02-06  Jon K Hellan  <hellan@acm.org>
+
+
Implement fast browsing of tooltips:
+

+
* gtk/gtktooltips.h (struct _GtkTooltips): Add sticky_delay,
+
use_sticky_delay and last_popdown
+
(gtk_tooltips_set_sticky_delay): Declare it.
+

+
* gtk/gtktooltips.c (gtk_tooltips_init): Initialize sticky_delay,
+
use_sticky_delay and last_popdown.
+
(gtk_tooltips_set_sticky_delay): New public function. Set sticky
+
delay.
+
(gtk_tooltips_draw_tips, gtk_tooltips_set_active_widget): Record
+
time of popdown.
+
(gtk_tooltips_set_active_widget): Unset sticky behaviour if widget
+
is NULL.
+
(gtk_tooltips_recently_shown): New static function.  Return true
+
if < sticky_delay has elapsed since last popdown.
+
(gtk_tooltips_event_handler): Display window after sticky_delay
+
(presumably < normal delay) if < STICKY_REVERT_DELAY has elapsed
+
since last popdown.
+
 Mon Feb  5 22:05:57 2001  Owen Taylor  <otaylor@redhat.com>
 
 	* gdk/linux-fb/gdkimage-fb.c (_gdk_fb_get_image): Fix syntax
Index: gtk/gtktooltips.h
===================================================================
RCS file: /cvs/gnome/gtk+/gtk/gtktooltips.h,v
retrieving revision 1.16
diff -u -r1.16 gtktooltips.h
--- gtk/gtktooltips.h	2000/08/30 00:33:38	1.16
+++ gtk/gtktooltips.h	2001/02/06 19:27:19
@@ -68,6 +68,9 @@
   guint   delay : 30;
   guint	  enabled : 1;
   gint	  timer_tag;
+  guint   sticky_delay;
+  gboolean use_sticky_delay;
+  GTimeVal last_popdown;
 };
 
 struct _GtkTooltipsClass
@@ -82,6 +85,8 @@
 void
	 gtk_tooltips_disable
   (GtkTooltips   *tooltips);
 void
	 gtk_tooltips_set_delay
   (GtkTooltips   *tooltips,
 
				    guint
   delay);
+void
	 gtk_tooltips_set_sticky_delay (GtkTooltips   *tooltips,
+
				    guint
   sticky_delay);
 void
	 gtk_tooltips_set_tip
   (GtkTooltips   *tooltips,
 
				    GtkWidget
  *widget,
 
				    const gchar   *tip_text,
Index: gtk/gtktooltips.c
===================================================================
RCS file: /cvs/gnome/gtk+/gtk/gtktooltips.c,v
retrieving revision 1.30
diff -u -r1.30 gtktooltips.c
--- gtk/gtktooltips.c	2000/12/04 16:11:51	1.30
+++ gtk/gtktooltips.c	2001/02/06 19:27:20
@@ -38,6 +38,8 @@
 
 
 #define DEFAULT_DELAY 500           /* Default delay in ms */
+#define STICKY_REVERT_DELAY 1000    /* Delay before sticky tooltips revert
+
			     * to normal */
 
 static void gtk_tooltips_class_init        (GtkTooltipsClass *klass);
 static void gtk_tooltips_init              (GtkTooltips      *tooltips);
@@ -103,8 +105,12 @@
   tooltips->tips_data_list = NULL;
   
   tooltips->delay = DEFAULT_DELAY;
+  tooltips->sticky_delay = 0;
   tooltips->enabled = TRUE;
   tooltips->timer_tag = 0;
+  tooltips->use_sticky_delay = FALSE;
+  tooltips->last_popdown.tv_sec = -1;
+  tooltips->last_popdown.tv_usec = -1;
 }
 
 GtkTooltips *
@@ -215,6 +221,16 @@
   tooltips->delay = delay;
 }
 
+void
+gtk_tooltips_set_sticky_delay (GtkTooltips *tooltips,
+
		       guint        sticky_delay)
+{
+  g_return_if_fail (tooltips != NULL);
+  g_return_if_fail (GTK_IS_TOOLTIPS (tooltips));
+
+  tooltips->sticky_delay = sticky_delay;
+}
+
 GtkTooltipsData*
 gtk_tooltips_data_get (GtkWidget       *widget)
 {
@@ -310,7 +326,10 @@
   if (!tooltips->tip_window)
     gtk_tooltips_force_window (tooltips);
   else if (GTK_WIDGET_VISIBLE (tooltips->tip_window))
-    gtk_widget_hide (tooltips->tip_window);
+    {
+      gtk_widget_hide (tooltips->tip_window);
+      g_get_current_time (&tooltips->last_popdown);
+    }
 
   gtk_widget_ensure_style (tooltips->tip_window);
   style = tooltips->tip_window->style;
@@ -369,7 +388,11 @@
                                 GtkWidget   *widget)
 {
   if (tooltips->tip_window)
-    gtk_widget_hide (tooltips->tip_window);
+    {
+      if (GTK_WIDGET_VISIBLE (tooltips->tip_window))
+
g_get_current_time (&tooltips->last_popdown);
+      gtk_widget_hide (tooltips->tip_window);
+    }
   if (tooltips->timer_tag)
     {
       gtk_timeout_remove (tooltips->timer_tag);
@@ -396,8 +419,24 @@
 	    }
 	}
     }
+  else
+    {
+      tooltips->use_sticky_delay = FALSE;
+    }
 }
 
+static gboolean
+gtk_tooltips_recently_shown (GtkTooltips *tooltips)
+{
+  GTimeVal now;
+  glong msec;
+  
+  g_get_current_time (&now);
+  msec = (now.tv_sec  - tooltips->last_popdown.tv_sec) * 1000 +
+
  (now.tv_usec - tooltips->last_popdown.tv_usec) / 1000;
+  return (msec < STICKY_REVERT_DELAY);
+}
+
 static gint
 gtk_tooltips_event_handler (GtkWidget *widget,
                             GdkEvent  *event)
@@ -429,14 +468,31 @@
       if (tooltips->enabled &&
 	  (!old_tips_data || old_tips_data->widget != widget))
 	{
+
  guint delay;
+
  
 	  gtk_tooltips_set_active_widget (tooltips, widget);
 	  
-
  tooltips->timer_tag = gtk_timeout_add (tooltips->delay,
+
  if (tooltips->use_sticky_delay  &&
+
      gtk_tooltips_recently_shown (tooltips))
+
    delay = tooltips->sticky_delay;
+
  else
+
    delay = tooltips->delay;
+
  tooltips->timer_tag = gtk_timeout_add (delay,
 
					 gtk_tooltips_timeout,
 
					 (gpointer) tooltips);
 	}
       break;
 
+    case GDK_LEAVE_NOTIFY:
+      {
+
gboolean use_sticky_delay;
+
+
use_sticky_delay = tooltips->tip_window &&
+
	GTK_WIDGET_VISIBLE (tooltips->tip_window);
+
gtk_tooltips_set_active_widget (tooltips, NULL);
+
tooltips->use_sticky_delay = use_sticky_delay;
+      }
+      break;
     default:
       gtk_tooltips_set_active_widget (tooltips, NULL);
       break;
Comment 1 Jon Kåre Hellan 2001-02-06 19:40:20 UTC
Created attachment 214 [details] [review]
bugzilla garbled the patch I entered in the description field, so here I try again
Comment 2 Owen Taylor 2001-02-06 22:23:07 UTC
I had some discussions with this with Tim on IRC the other
day - we discussed some more radical changes to GtkTooltips,
such as:

 a) Storing tip information on the widget (or retrieving
    it with a signal from the widget)
 b) Getting rid of the GtkTooltips object or making it
    a singleton.

It's not clear if we can make these changes for 2.0 or not,
but the general plan for tooltips is to change it a bit
more radically.
Comment 3 Havoc Pennington 2001-02-12 20:02:34 UTC
Should put in the tooltip browsing even if tooltips don't get reworked
for 2.0. The browse delay need not be hardcoded, can be a style property.
Comment 4 Havoc Pennington 2001-02-17 17:02:57 UTC
I'm applying the sticky delay patch, with a small change (removed
set_sticky_delay(), I don't see why we have set_delay() either).
Retitling the bug "Rework tooltips" and punting to a future milestone
for the stuff Owen and Tim discussed about redoing tooltips.
Comment 5 Owen Taylor 2001-02-18 21:31:11 UTC
*** Bug 51035 has been marked as a duplicate of this bug. ***
Comment 6 Zack Rusin 2002-02-24 07:23:01 UTC
Created attachment 6835 [details] [review]
allocates GtkTooltipsData using memchunks (from TODO)
Comment 7 Owen Taylor 2002-07-30 22:08:58 UTC
*** Bug 86332 has been marked as a duplicate of this bug. ***
Comment 8 Matthias Clasen 2003-01-02 23:37:28 UTC
Move bugs which are tracking planned 2.4 features to the proper target
milestones.
Comment 9 Christof Petig 2004-10-15 09:13:36 UTC
I added some comments to bug #80980 which indicate that a signal (or a function
pointer) is indead needed to query the widget for the text to display. The
relative pointer position would be needed as parameters.
Comment 10 Mariano Suárez-Alvarez 2007-02-11 11:20:39 UTC
Do Kris' new tooltips close this bug?
Comment 11 Tim Janik 2007-02-11 14:23:47 UTC
(In reply to comment #10)
> Do Kris' new tooltips close this bug?

various things/features/etc. have been raised in this report which has an all too general subject. the mentioned items may or may not be resolved by the new tooltip code, so it's probably best to close this bug and wait for new bugs being filed against the new tooltip code, in case any of the problems remain.