GNOME.org
 

Re: Tooltips patch [take 1]

On Wed, 11 Oct 2006, Kristian Rietveld wrote:


On Wed, Sep 27, 2006 at 03:31:21PM +0200, Tim Janik wrote:

On Thu, 20 Jul 2006, Kristian Rietveld wrote:

 * What to do with gtk_tooltip_force_query_tooltip() and
   gtk_tooltip_force_query_tooltip_for_widget().  The former will look up
   the widget under the mouse pointer and immediately display that
   tooltip.


that's not what was discussed/proposed though. force_query should simply
trigger the normal what-tooltip-is-needed-where logic that is also triggered
when the mouse moves. that's so that applications can notify gtk about the
need to display a (new) tooltip, but the usual tooltip behaviour like timeouts
is preserved.


That is one thing we need, but also ...


   But I also see uses (and IIRC this has also been requested),
   to immediately show the tooltip of a specific widget.


i'm not sure what use case you're referring to, can you please elaborate?


... there have been requests for (immediately) showing tooltips on-demand:

 http://mail.gnome.org/archives/gtk-devel-list/2006-January/msg00262.html


this one has no description of a use case for on-demand tooltips display.


 http://mail.gnome.org/archives/gtk-devel-list/2006-January/msg00278.html


this is really a request for a new category of event notification windows or
tutor information windows that are not (yet/currently) part of the scope
adressed by the new tooltips proposal. and i'd actually like to wait with
adressing these issues because it will be easy to extend the tooltip API
in the future *if* it turns out to be the proper mechanism to cover this
new category of info window applications.
to put this another way, i'm not entirely sure our currently proposed Tooltip
code is the right mechanism to really implement this functionality, e.g.
because event notification/tutor information could just as well be seperate
windows with a "Dismiss"/etc confirmation button.


 http://mail.gnome.org/archives/gtk-devel-list/2006-April/msg00023.html


the use cases referred to in the follow ups of this post either fall into
the touchscreen category (which is better to adress *after* an initial tooltip
version went into CVS and that we have adressed to some extend in private
email already) or are already covered by our current ::query-tooltip() API.

so to sum up, there has been no use cases mentioned so far which we explicitely
meant to adress, that would require demand showing of tooltips with bypassing
gtk's standard timeout handling and/or positioning logic.
that means, we should not add API to do this at this point.


Use cases I can think of are more like "notification tips".  Do we want to
support those with the tooltips code?  Think of the "New software
installed" tooltip in Windows (triggered by code, positioned by code),
or the notifications in the modern GNOME desktop.


i'd like to investigate the general notion of event notification or tutorial
tipping first, and possible interaction with existing tooltips, before we
rush on to the implementation side of things. this should be investigated
under a different subject... but to throw up an example interaction problem:
does normal tooltipping work when hovering the mouse over tippable widgets
while a notification is displayed?




   This probably
   also needs to display the tooltip above/below the widget and not
   the mouse pointer.  Once we decide on a set of functions we should add
   those to the header file.


i'd really like to nail the use cases here first, otherwise we'll end up
with some wild useless API growth once more. the former API discussions
tried to adress all use cases raised, either there's some misunderstanding
in how those are covered, or you're referring to cases not yet raised.
in either case, a bit of elaboration will help ;)


 * Also, do we want to be able to set a positioning function?


use cases? (again ;)


The notification tips mentioned above or maybe something like the tips
on tree view rows which were discussed on this list earlier.  (However
having the tooltip right below the mouse pointer is probably troublesome
wrt event handling).


it might be worth the effort to try to get the automatic positioning going
good enough for the common cases, including tooltip positioning for treeviews.
so that we don't have to support cutom (per-widget) tip positioning functions.
that is not only important for simplicity of the tooltip API and implementation, but also in light of theme or platform (e.g. touchscreen mode) 
hooks to customize display wide tooltip window appearance and positions.


one related use case that comes to my mind here is the info window in the
maemo platform which is essentially used to display status information and
tooltips.
for that it's probably better to plug something even more generic like a
tooltips display function that can also adjust the tooltip's GtkWindow by
setting up styles, etc.


That could happen (pretty sure about the tooltips case, less about the
status info case) in the query-tooltip callback if you use a custom
GtkWindow for the tooltip.


no, solving this per ::query-tooltip() callback means intermixing theming
and touchscreen mode hooks with the tooltip implementation of *every*
widget. that'd be the wrong place for this type of stylization. instead,
themes should be able to install per-display tooltip hooks to adat tip
window styles and if necessary positions.


Also, in a discussion earlier on this list it was mentioned that theme
engines should be able to configure/customize the positioning of the
tooltip:

 http://mail.gnome.org/archives/gtk-devel-list/2006-April/msg00204.html

We are going to need some API for this, right?


yes. a detailed proposal for this is yet to come though, and this doesn't
need to hold off the general tooltip development process. (it's basically
just virtualizing of existing functionality which can be done at a later
point.)


   widget_signals[SHOW] =
     g_signal_new (I_("show"),
 		  G_TYPE_FROM_CLASS (gobject_class),
@@ -1388,6 +1421,18 @@ gtk_widget_class_init (GtkWidgetClass *k
 		  _gtk_marshal_BOOLEAN__BOXED,
 		  G_TYPE_BOOLEAN, 1,
 		  GDK_TYPE_EVENT | G_SIGNAL_TYPE_STATIC_SCOPE);
+  widget_signals[QUERY_TOOLTIP] =
+    g_signal_new (I_("query_tooltip"),


nit pick, the canonical name here is query-tooltip.


Is there actually a standard for canonical names?


yes.


(Isn't it -?)


yes, '-' is the canonical delimiter for property names and signal names.


The names in
gtkwidget.c and several other widgets seem to use both - and _.


that might be due to historic reasons or lack of nit picking by the
maintainers ;)
not using '-' usually prevents glib/gtk+ from optimizing in terms of
memory or speed and takes the libraries extra effort to handle.


@@ -1274,6 +1275,13 @@ gtk_main_do_event (GdkEvent *event)
     {
       _gtk_clipboard_handle_event (&event->owner_change);
       return;
+    }
+
+  if (event->type == GDK_LEAVE_NOTIFY
+      || event->type == GDK_MOTION_NOTIFY
+      || event->type == GDK_SCROLL)
+    {
+      _gtk_tooltip_handle_event (event);


hm, why exactly isn't GDK_ENTER_NOTIFY also interesting here?


We don't use EnterNotify to determine whether we need to start the
tooltip delay.  We start the tooltip delay once we have received a
MotionNotify event.


X may opt to *not* send a motion event, if instead it can send an
enter/leave event because the motion also crossed window boundaries.
in effect, that means you need to also catch enter/leave events and
treat them as ordinary motion, in order to cover all mouse motions
of interest for tooltips.


all in all, this looks like a substantial prototype implementation
already, but it's certainly still lacking in some key areas.
in any case, it's so large already, that patch+review is becoming
tedious as development process, therefore i think we should get this
into CVS in its current form and build/extend/fix from there.
a branch might be good for that but it wouldn't be too bad having it
in HEAD already either.
that'll also allow concurrent hacking on the new tooltip implementation.


I am almost done processing all of your comments.  I think it's a good
idea to post a patch here once more and then commit on HEAD and continue
from there.


ok, great. will do as you say then ;)


thanks,

-kris.


---
ciaoTJ
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]