Re: Callback based tooltips (Re: New tooltips API, continued)

[Kristian Rietveld <kris imendio com>]

On Mon, Apr 24, 2006 at 06:24:23PM +0200, Tim Janik wrote:
> > For 
> >tooltip texts we would just need a way to get hold of GtkTooltip outside 
> >of the query_tooltip callback ...
> 
> i'm not sure what you mean here. what do you want "tooltip texts" for? or 
> what
> is that in the first place?

With "tooltip texts" I actually meant the contents of a tooltip.  The
point here is that we might want to have a way to change the tooltip
text/contents when the tooltip is already visible.  But looking at
things again, this is probably a non-issue, since:

  * When using the tooltip-markup property, we can just update the text
    in the tooltip when the value of the property changes.
  * The programmer can save the pointer to the GtkTooltip and use the
    setters to change the contents while the tooltip is visible (we
    probably are going to need a way to notify the programmer that the
    tooltip isn't visible anymore/invalid).
  * We have gtk_widget_get_tooltip_window() for the complex case.

> >When using a custom tooltip window, who would handle popping up/down that 
> >window?  Is the idea to pop up/down the window from a 
> >query_tooltip_callback()?
> 
> no, this would still be completely up to the gtk logic, the user can just
> provide his own window to be used for tooltipping by gtk.

Sounds like a good plan.

> no reasoning has been provided so far for shortening the second tip delay
> for a limited set of widgets only though. or to put it in your words, what's
> the reason for not having *all* widgets in the same tooltip group?

That's a good question, I wouldn't have a problem with dropping the
grouping alltogether and make it a default behaviour.  But I'm not an UI
expert ...

> >>- querying tooltips via ::query_tooltip() will also be easily customizable
> >>  via connecting signal handlers to widgets, and it will work for 
> >>insensitive
> >>  widgets even with area sensitive tooltips. especially the latter isn't 
> >>really
> >>  covered by your proposal afaiu but an often requested feature.
> >
> >I don't fully understand what you mean here; but tooltips for insenstive 
> >widgets would just work fine with the API in my proposal.
> 
> really? maybe i'm missing something about your proposal, so let me explain:
> imagine you want to display graph coordinates in a tooltip, i.e. similar
> to the coordinates displayed in the lower left of a gnuplot window.
> afaiu your porposal requires setting of myriads of event areas for this
> *or* widget side event handling. the former will be grossly excessive in
> memory usage and the latter won't work for insensitive widgets.

Ok, so with the above you just mean connecting a widget to the
query_tooltip signal so the widget gets to set the tooltip (basically
what GtkTreeView is going to do).

> well, i'd guess the solution to this is as simple as having gtk internals
> watch Ctrl+F1 to fire up tooltips with timeout=0 and x=-1, y=-1.

Probably ;)

> >dynamically 
> >changing tooltip texts and agree on how to handle custom tooltip windows.
> 
> is there anything about dynamic tooltip contents that is not covered by the
> mouse pointer relative emission of ::query-tooltips and maybe very rare uses
> of gtk_display_force_tooltip_query() in case a tip changes while the mouse
> pointer stands still?

The contents can change while the mouse pointer stands still.  But I've
addressed this in the beginning of my mail.

> >I 
> >hope we can agree on these issues soon, so I can come up with a patch 
> >before the middle of next week.
> 
> sorry, couldn't reply in time for that objective ;)

Still hope we can agree soon so I can write the patch ;)


thanks,

-kris.