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

On Tue, 25 Apr 2006, Kristian Rietveld wrote:

On Mon, Apr 24, 2006 at 06:24:23PM +0200, Tim Janik wrote:
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
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
 widgets even with area sensitive tooltips. especially the latter isn't
 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.

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)



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]