Re: [Usability] HIG has severe "MS Windows" flaws.

[Soeren Sandmann <sandmann daimi au dk>]

Curtis Hovey <sinzui cox net> writes:

> Works well for me in G 2.6, but the behavior can appear erratic.  The
> delay is canceled when the mouse moves over something meaningful in the
> menu.  That meaningful something is usually text, usually on the
> opposite side the submenu is appearing on.  So I can move my mouse down
> a number of items in the menu before I get to the submenu, so long as
> the text of those menus are short.

The rule is: Submenu stays up as long as pointer is inside the
triangle spanned by (A) the pixel where the pointer left the menu
item, (B) the top left corner of the submenu, and (C) 50 pixels below
the bottom left corner of the submenu.

After spending 1000 ms in this triangle without entering the submenu,
the submenu is removed and whatever item you are hovering above is
selected instead.

The algorithm is basically copied from Mac OS (both classic and X),
with some differences in timing:

        - GTK+ submenus pop up after 225 ms by default, where Mac OS
          submenus pop up a little faster, perhaps 200 ms.

        - GTK+ sets the triangle timeout at 1 s by default, where
          Mac OS uses something like 1.5 s.

This triangle algorithm has been in GTK+ since 1.2, but until 2.2 it
was so buggy and unpredictable that moving in a straight line was
really the only way to use the menus.

Note that Mozilla/Firefox/Thunderbird menus (and the rest of their
interfaces for that matter) have nothing to do with GTK+, although
they may _look_ like GTK+.

(For people building their own GTK+'s, try changing

#undef DRAW_STAY_UP_TRIANGLE

into

#define DRAW_STAY_UP_TRIANGLE

on line 3051 in gtkmenu.c to get a visual representation of the triangle)


Søren