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. 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. -- Shahms E. King <shahms shahms com> Multnomah ESD Public Key: http://shahms.mesd.k12.or.us/~sking/shahms.asc Fingerprint: 1612 054B CE92 8770 F1EA AB1B FEAB 3636 45B2 D75B
Attachment:
signature.asc
Description: This is a digitally signed message part