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

[Tim Janik <timj gtk org>]

On Thu, 6 Apr 2006, Yevgen Muntyan wrote:

> Tim Janik wrote:
>
> > hm, can you please explain the use case for forefully displaying tooltips?
> > as opposed to waiting for the usual user configurable timeout and honour
> > user settings like display-tooltips = off ?
>
> Such a use case would not necessarily ignore user settings. It could be a 
> canvas,
> where tooltip should be shown over specific areas/objects; i.e. a thing like 
> container
> widget with children which are not widgets. Note that it's not the same as
> area-specific widget tooltips, e.g. one may want to have tooltip timeout
> be triggered only when cursor is over some object but not when it's over
> blank space.

i don't understand the distinction between "blank space" and "object" you're
making here. it should be pretty simple actually, once the mouse cursor moved,
::query-tooltips() is emitted after the configured tooltip-timeout, and then
your signal handlers get to decide whether a specific location has a tooltip
or not.

the only case that's not fully covered by this is:
1) area foo has no tooltip
2) mouse moves into area foo
3) tooltip-timeout expires
4) ::query-tooltip() is emitted
5) query_tooltip_handler() returns FALSE; // there's no tooltip here (yet)
6) application changes state
7) application sets (or changes) tooltip on area foo

in this case, the tip won't neccessarily be updated without
the mouse moving. however that case should be pretty rare and
may not even be usually noticable.
however, it can be helped by exposing some function the tooltip
implementation will require anyway, i.e.:

void gtk_display_force_tooltip_query (GdkDisplay*); /* display may be NULL */

this'd basically enforce a jump to (4) if tooltip timeout has already expired,
or causes the timeout to be restarted.
it'd not usually be required to be called by user code though.

> Best regards,
> Yevgen

---
ciaoTJ