Opened 10 years ago

Closed 5 years ago

Last modified 5 years ago

#11703 closed enhancement (fixed)

[Interface Kit] shorten menu delay

Reported by: diver Owned by: nobody
Priority: normal Milestone: R1/beta2
Component: Kits/Interface Kit Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description

Currently, kOpenSubmenuDelay is set to 225000 (1/4 of a second) which is definitely way too much. This value came from this patch attachment:menu-diagonal-movement3.patch:ticket:284

"open submenus after a 0.2 sec delay to make menu browsing smoother - moving a cursor quickly down a menu doesn't cause submenus to quickly appear and disappear while the cursor flies over an item with submenu)"

However, in R5 there was no delay at all which was one of the reason it felt so fast.

Change History (5)

comment:1 by anevilyak, 10 years ago

I'm going to have to disagree on this. IMHO, the lack of delay in the hrev5 menus was one of the single worst decisions they made. It may feel fast, but it's horrible for usability because it leaves no room for error, especially since menu items are quite small targets. I lost count of how often I'd lose whatever folder I was browsing in R5 because of a small movement, and I'd further note that this is precisely why every other UI out there has similar delays in menus. Also, without them, the feature that the patch in question introduced (diagonal) is basically impossible to implement.

Version 0, edited 10 years ago by anevilyak (next)

comment:2 by pulkomandy, 10 years ago

We discussed this with Diver on IRC, and the 0.2 second delay is too long and easily noticeable. It is also not strictly needed for diagonal navigation: there is another (longer) delay for this. It is currently set to about 1 second. However, removing the short initial delay would make the first submenu open immediately, and if a diagonal move is detected, no other submenu can be reached for 1 second.

One solution could be to use an adaptative delay. I think it's possible to detect when the mouse is slowing down as it gets close to the target menu item and shorten the delay then, but make it longer when the mouse is starting to move again (possibly to move into the submenu). Other ways to detect this could use the mouse direction (if it's mostly vertical, the mouse is likely not trying to go into a submenu)

Diagonal menus without delay are possible as seen for example on Amazon's website: http://bjk5.com/post/44698559168/breaking-down-amazons-mega-dropdown

comment:3 by axeld, 8 years ago

Owner: changed from axeld to nobody
Status: newassigned

comment:4 by waddlesplash, 5 years ago

Resolution: fixed
Status: assignedclosed

Patch merged in hrev53920.

comment:5 by nielx, 5 years ago

Milestone: R1R1/beta2

Assign tickets with status=closed and resolution=fixed within the R1/beta2 development window to the R1/beta2 Milestone

Note: See TracTickets for help on using tickets.