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

[Tim Janik <timj imendio com>]

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
> > tooltip-less area
> > 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
> of grouping.

well, given that behaviour is implemented, there's no need for seperate
groups, right?

> I once wrote down how tooltips should behave:
>
> Tooltips:
> ---------
>        - 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
>          tooltips displayed.
>
>        - 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
>          generated).

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

> Soren

---
ciaoTJ