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

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

- 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 # Want to see tooltips also for disabled buttons
which is one of the outstanding N770 bugs, listed here:

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




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