Re: Callback based tooltips (Re: New tooltips API, continued)
- From: Tim Janik <timj imendio com>
- To: Soeren Sandmann <sandmann daimi au dk>
- Cc: Gtk+ Developers <gtk-devel-list gnome org>
- Subject: Re: Callback based tooltips (Re: New tooltips API, continued)
- Date: Tue, 25 Apr 2006 15:25:15 +0200 (CEST)
On Tue, 25 Apr 2006, Soeren Sandmann wrote:
"Matthias Clasen" <matthias clasen gmail com> writes:
On 4/25/06, Tim Janik <timj imendio com> wrote:
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.
Well, one reason would be that it is in our current tooltip support, and we
don't just remove features for no reason...
The reason for its existance is that it is annoying to have to wait for every
other tooltip again when you are moving the mouse over the toolbar to see
them all. And of course, putting all tooltips in one group makes the behaviour
of tooltips equally annoying, since you then have to hunt for a
to get out of fast-tooltip mode again...
That's because that feature simply doesn't work. Moving the mouse to a
tooltip-less area does not turn off fast mode as it should, regardless
well, given that behaviour is implemented, there's no need for seperate
I once wrote down how tooltips should behave:
- Tooltips are too intrusive. The text should be smaller, and
they should to the right of the cursor, and a little below
the cursor's center.
| | tooltip |
not centered below the cursor.
sounds like a good default, but should be configurable/customizable by
the theme engine.
- In "normal" mode, tooltips should appear after ~1.5 s.
same here, that's a reasonable default for some users but needs to be
configurable (prolly per-display).
- When in "browse" mmode (tooltips appear immediately),
tooltips should not actually appear immediately, but rather
after ~75-100 ms of the mouse cursor not moving, so that you
can move over a set of objects without getting a ton of
- After a period of around 500ms without any tooltip being
displayed, "browse" mode should be turned of. (That way you
can get rid of tooltips by shaking the mouse a bit).
Soeren, can you provide reasoning for seperate groups once this behaviour
is in place?
- Browse mode should be turned off when you leave the area of
the tooltip group.
what's thr rationale here? why shouldn't browse mode continue, say on the next
group of text entry fields after browsing toolbar tooltips?
or phrased differently, wehn in browse mode, why should the user wait *extra*
time for some of the tooltips and not others?
- They should not appear before we have seen at least one
motion event on the widget (ie. stuff that pops up under the
mouse should not get a tooltip). (Or possibly an 'enter'
that doesn't come from popping up if such a thing can be
and exception to this (e.g. in the tree view) is prolly either:
a) a tooltips is already shown, and the view scrolls to a new tip,
b) no tooltip is already shown and the view scrolls to a new tip.
i think it's pretty clear that you want an update on (a), i'm not so sure
on whether you want the tip to pop up on (b) though, and if that feels nice
in conjunction with the tooltip timeout.
] [Thread Prev