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

[Soeren Sandmann <sandmann daimi au dk>]

Tim Janik <timj imendio com> writes:

> > 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 am not really arguing for (or against) groups. I think 'groups', if
implemented, should probably not have any representation in the UI
though. They might be useful in the API.

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

Right, replace 'the area of the tooltip group' with 'the set of
widgets that have tooltips'. The important thing is, if the cursor
moves to a place where there are no tooltips, browse mode should be
turned off.

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

A view scrolling under the mouse cursor should generally be counted as
motion, I think.


Soren