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

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.




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