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

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

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.



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