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

[Tim Janik <timj imendio com>]

On Tue, 25 Apr 2006, Kristian Rietveld wrote:

> 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.

no, the programmer/user really shouldn't keep a GtkTooltip* pointer around
and try to change the tip outside of ::query-tooltip. there's no neccessity
for this, even if the tip changes while already being displayed.
this is the case i mentioned with gtk_display_force_tooltip_query().
if the tip changes, the user code can call gtk_display_force_tooltip_query()
which will simply cause a new emission of ::query-tooltips, therein, the
new text can be set.
in a sense, this is meant to be similar to the ::expose-event signal, if
you want to change screen contents, just queue_redraw() and let ::expose-event
do the rest.

> > 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 ...

i don't think there's a point in implementing grouping unless the above
question has been answered, i.e. we've gotten a resonable usage scenario.
so until that happens, it's probably best to leave groups out of the API spec.

> > > > - 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).

yes, everything customizable happens in handlers of ::query-tooltips, and
gtk+ cares about emitting ::query-tooltips with the required granularity.
i.e. upon mouse position changes, and for tooltip popups because:
- the initial delay has expired after entering
- the secondary delay has expired (probably 0 with all-in-one-group)
- gtk_display_force_tooltip_query() has been issued while a tooltip was up.
- scrolling occoured under the mouse while a tooltip was up.

> > > 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.

as i said, that is the case where user code should/can call
gtk_display_force_tooltip_query(). (and gtk internals would also
call gtk_display_force_tooltip_query() when the tooltip window
or tooltip markup property change)

> -kris.

---
ciaoTJ