Opened 10 years ago

Closed 10 years ago

Last modified 6 years ago

#9062 closed feature (wontfix)

ui-menu widget configurable delay

Reported by: Edmund Owned by:
Priority: minor Milestone: none
Component: Version: 1.10.0
Keywords: Cc:
Blocked by: Blocking:


Would it be possible in a future version of the UI to allow the menu item to have a configurable delay, I think the default of 300 was far too long and I've hard coded it down to 1 but I'm not sure if this could affect other widgets which may use it, in addition I'm curious as to why it was hard coded, is there a known issue when it is set too low?


Change History (3)

comment:1 Changed 10 years ago by Scott González

Resolution: wontfix
Status: newclosed

The delay is an implementation detail. Users shouldn't be configuring it, so we're definitely not going to expose it as an option. Ideally the delay is dynamic based on the direction the mouse is mousing. If you'd like to take a stab at implementing a smarter delay, we can try to land that, but exposing a new option is extremely unlikely to happen.

comment:2 Changed 10 years ago by Edmund

Ok thanks a lot for the response :)

Last edited 10 years ago by Edmund (previous) (diff)

comment:3 Changed 6 years ago by GSPP

The delay being an implementation detail seems not required. It could be made into contractual behavior.

The way the delay works now makes the menu feel very sluggish. I consider this a dealbreaker. Not sure who wants their menus to behave that way...? The menu widget is great otherwise so I'll be hacking around this.

The delay certainly is useful when moving the mouse out of the menu entirely. Any small such mistake would close everything. But at least when moving between adjacent menu items the delay should be zero.

I always find that Windows menus behave in exactly the right way. This is what they do as well. It's the only thing that kept the huge Windows XP start menu working at all :)

Note: See TracTickets for help on using tickets.