"Matthias Clasen" <[EMAIL PROTECTED]> writes: > On 4/25/06, Tim Janik <[EMAIL PROTECTED]> 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. 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. - In "normal" mode, tooltips should appear after ~1.5 s. - 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). - Browse mode should be turned off when you leave the area of the tooltip group. - 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). Soren _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list