Re: RFC: Tooltips redesign (needed e.g. for row dependent tips in treeview)

[Gabriel de Perthuis <Gabriel de-Perthuis laPoste net>]

Le vendredi 22 octobre 2004 �1:35 -0700, Shahms King a �it :
> On Fri, 2004-10-22 at 18:47 +0200, Christof Petig wrote:
> > Hi,
> > 
> > After having commented on bug #80980 and #50619 without an answer in a 
> > week I'm asking here for further comments.
> > 
> > Up to now the tooltip design is based on a static tip per widget. To 
> > support per row (or column or cell) tooltips in treeview the tooltip API 
> > has to get redesigned.
> > 
> > Two possible implementations come to my mind:
> > 
> > 1) Adding the option of using a function pointer as an argument to 
> > gtk_tooltips_set_tip. Storing that in GtkTooltipsData and using it (if 
> > !=NULL) to query the tip according to the relative mouse position. 
> > [perhaps using a boolean argument to distinguish between normal and 
> > private tip].
> > 
> > E.g. void gtk_tooltips_set_tip_function(GtkTooltips   *tooltips, 
> > GtkWidget *widget, const gchar *(fun)(GtkWidget*,gint x,gint y,gboolean 
> > private_tip));
> > 
> > This option keeps the current logic of an (widget-)external tip object.
> > 
> > 2) Adding a signal to each widget to query for the matching tip. (three 
> > arguments: x,y,private) call this signal if there is no tip registered 
> > for this widget. This could gradually eliminate the need to store the 
> > tips outside of the widget structure.
> > 
> > This option delegates figuring out the tip text back to the widget.
> > 
> > Which way to go? (I'd prefer 2 since I do not know the reason for 
> > starting with 1 in the past).
> > 
> > Any ideas, comments, criticism, unfinished patches?
> >     Christof
> 
> I've been interested in this myself for a while now, but haven't had
> time to do any work on it.  I'd have to say that option 2 is probably
> the most reasonable.  From reading the various comments in the bugs it
> seems like having the widget be semi-responsible for showing its own
> tooltip is the direction to go.
> 
> Right now, the GtkTooltips widget is responsible for determining the
> text to be rendered as well as when and where it should be displayed.
> Putting the "when and where" logic in GtkTooltips is (mostly) what keeps
> it tied to GtkWidgets without NO_WINDOW and is clearly the first thing
> that needs to be managed by the widget itself.
> 
> Pulling the "when and where" into the tool-tipped object requires a
> signal like "tooltip-show" (and possibly "tooltip-hide").  Having the
> "tooltip-show" signal pass in the "preferred" x and y coordinates, as
> you suggest, solves the "when and where" problem and also allows
> alternative tooltip implementations really easily.  Given that the
> tip_private isn't actually used anywhere in the current tooltip code, I
> don't see a lot of value in having the widget pass that as part of the
> signal.
> 
> Managing the tooltip text on the widget seems wrong to me.  It does
> provide the advantage of making the most basic use-case of setting a
> tooltip on a widget extremely simple, but means that anything
> "else" (like private tips, fancy HTML formatted tips, etc.) needs to be
> managed differently from the simple case and it feels wrong.
Adding signals seems right, but that wouldn't mean the widget should
display its tooltips by itself. It should choose what text to display,
and immediately give it back (along with the target widget) to some
render_tooltip method, preferably as text. Otherwise there wouldn't be
consistency in appearance , timeouts, and whatever.
Mind that this draw_tooltip method shouldn't be call with coordinates,
because tooltips could for instance follow the mouse.
It should be called on the widget instead.
So really this method would be just the same as tooltip_set_text, only
it would be called from handlers for appropriate signals. The only thing
left to do is to add these signals.

> So, IMHO, the route to take would be to write a GtkTooltipable interface
> consisting of two signals:
> tooltip-show (x, y)
> tooltip-hide ()
> 
> and have GtkWidget and GtkCellRenderer (or a specific
> GtkCellRendererTooltip) implement that interface.
> 
> At that point the GtkTooltips API can be implemented in terms of
> GtkTooltipable instead of GtkWidget.  I'm not sure how changing the
> prototypes and declarations of gtk_tooltips_set_tip() and
> GtkTooltipsInfo from GtkWidget* -> GtkTooltipable* impacts the API
> stability, however.  You might have to add GtkTooltipsInfoFull and
> gtk_tooltips_set_tip_full() or similar.