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

[Tim Janik <timj imendio com>]

On Tue, 11 Apr 2006, Kristian Rietveld wrote:

> Tim Janik wrote:

> We do agree that we should have a tooltip-markup property on widgets. The 
> "query_tooltip" signal has some things in common with the "populate_tooltip" 
> signal we added in my proposal.  As an afterthought, I guess the fact that we 
> added a "populate_tooltip" signal actually indicates that a callback-based is 
> wished ...
>
> The point where our proposals really differ is at handling complex tooltips. 
> I think we should go with your approach, if we can fix the problems raised 
> which led Owen to come up with an alternative approach:
> * Tooltips should be available on demand by the keyboard (already raised in 
> this thread),

i spent some thought on this after it had been raised in one of the replies
to my proposal, basically, it's the same as wanting a normal mouse-based
tooltip except that with the keyboared ypu obviously can't tip pointer position
related contents. so the simplest thing is probably to still emit
::query-tooltip, just with with x=-1, y=-1. provided this is properly
documented, ::query-tooltip implementors can choose to provide position
relative information and do general keyboard tipping in the same callback.

> * Extensibility, which has already been solved with the idea of allowing the 
> widget user to set a custom tooltip window,

yeah, i tried to match the requirements solved by your proposal in this regard.

> * Cases where tooltip texts or tooltip areas change dynamically. Tooltips 
> areas change when for example scrolling in a GtkTreeView, I guess this is 
> already handled by the fact that we will query for a tooltip again when the 
> pointer moves (where we might also want to re-query on scroll events).

yes, right. and btw, gtk should generally synthesize pointer-motion events when
scrolling, not doing so often causes update-bugs. in any case, this'd have
to re-query tooltips, yes.

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

> * We also add in that we need the ability to display the tooltip on-demand, 
> which has been raised at a later point.

i adressed this in another reply (From: Tim Janik <timj gtk org>, Date: Thu,
6 Apr 2006 16:55:27 +0200 (CEST), Subject: Re: Callback based tooltips (Re: New
tooltips API, continued)) where i suggested to expose:
void gtk_display_force_tooltip_query (GdkDisplay*); /* display may be NULL */
so yes, this is also been taken care of. though i expect this to be really
rarely used; i don't know of a reasonable use case other than the corner-case
described in my reply.


> > it also coveres moderately advanced cases with gtk_tooltip_set_icon() and
> > gtk_tooltip_set_custom(). for real adventurous tooltipping, people can use
> > gtk_widget_set_tooltip_window() and mess up their custom window instead
> > of GtkTooltip inside of a ::query_tooltip() handler. the common case
> > however would be to not make use of gtk_widget_set_tooltip_window().
>
> 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.
(kinda like you lending me a screwdriver to work with for a while, and i'll
use my own again when you take it back ;)

> > - for area specific tooltipping, widgets don't need to track the mouse
> >   pointer themselves. once gtk is in tooltip mode, ::query_tooltip() is
> >   simply emitted as the pointer moves.
>
> And as said above, maybe also on scroll events.

yep, full ACK.

> > - in constrast to your proposal, the decision of *when* to popup tooltips,
> >   and how long they are left up is completely up to gtk. this is actually
> >   meant to improve user experience, since gtk can honour per-display
> >   tooltip behaviour settings, and tooltip popup behaviour will be 
> > consistent
> >   across widgets on the same display.
>
> In my proposal gtk+ would decide when to pop up/down the tooltips for all 
> tooltips, except for the most complex case where one provides a 
> GtkTooltipWindow themselves.

that case is still covered by gtk+ in my proposal. reasoning already provided
above.

> > - there's no "grouping" of tooltips provided. for one, that's because i
> >   don't really understand the use case for that. once in tooltip mode, all
> >   widget tooltips can simply be popped up/changed seemlessly, until some
> >   significant user action forces leave of tooltip mode again (button press,
> >   key press).
> >   and for another, if grouping really is required, that can still be
> >   implemented after the fact with API similar to what you suggested.
>
> One of the usecases of grouping can, for example, be found in toolbars. 
> Toolbars have multiple buttons/items, which are all different widgets.  If 
> the tooltip is already displayed for one item and the mouse is moved to 
> another item on the toolbar, you usually do not want to wait for the new 
> tooltip to popup.  The solution here is to create a tooltip group and include 
> all items on the toolbar.

no, the use case you describe is just reasoning to shorten/eliminate the
tooltip popup-delay when we already display a tooltip and you're moving to
a different widget. that i fully agree with, it's common UI behaviour and
most probably expected by the user.

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?
when a user is reading/searching tooltips by moving the mouse to re-enter
widget after widget, there's no good reason to introduce extra delays for
some widgets or some widget transitions and not for others.

> > - because GtkTooltip is opaque and basically just implements a limited
> >   set of tip setters, future versions could allow gtk-wide or per-display
> >   plugging of tooltip objects. this could be interesting for embedded
> >   devices, respectively touchscreens, which may want to display tooltips
> >   in a non-standard way. e.g. an "info popup" in the upper right corner
> >   like the N770 has it. it also would cover themes that want to implement
> >   specialized tooltip display.
>
> This is an interesting win with your proposal.

well, coincidentally ;) this is required to fix
  http://bugzilla.gnome.org/show_bug.cgi?id=65490 # Want to see tooltips also for disabled buttons
which is one of the outstanding N770 bugs, listed here:
  http://maemo.org/maemowiki/MaemoGtk26Contributions#features

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

> > well, sorry for coming back so late. hope i could provide some usefull
> > input anyway ;)
>
> You sure did :).  As I said earlier, I pretty much prefer your simpler 
> proposal once we find solutions for the keyboard handling (which will 
> probably automatically give us API for ondemand tooltips?),

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.

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

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

> thanks,
>
> -kris.

---
ciaoTJ