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

[Kristian Rietveld <kris imendio com>]

Tim Janik wrote:
> reading your proposal for the first time (both versions of it), i can't 
> help the
> feeling that it seems a bit complicated (with nesting tip areas etc.) at 
> least
> from a widget user perspective.
> i'm wondering if a callback based approach wouldn't ease the whole setup 
> a lot,
> so to brainstorm for a second:

It looks like that our proposals have a lot in common at the higher 
level, but we have different thoughts on the details.  This might be 
caused by the complexity of GtkTooltipWindow in my proposal.  While I 
started out with a small callback based setup in the past (long before I 
managed to send out the first proposal), I was pointed to a mail from 
Owen [1] where he explained his issues with a callback-based approach. 
His sketch of an alternate approach looked reasonable to me, so I 
decided to go on with that and fill in the details (some of which still 
remain to filled in though).

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),
 * Extensibility, which has already been solved with the idea of 
allowing the widget user to set a custom tooltip window,
 * 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).  For tooltip texts we would just need a way 
to get hold of GtkTooltip outside of the query_tooltip callback ...
 * We also add in that we need the ability to display the tooltip 
on-demand, which has been raised at a later point.

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

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

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

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

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

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

> 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?), dynamically 
changing tooltip texts and agree on how to handle custom tooltip 
windows.  I hope we can agree on these issues soon, so I can come up 
with a patch before the middle of next week.



thanks,

-kris.


[1]http://mail.gnome.org/archives/gtk-devel-list/2004-October/msg00120.html