#9062 closed feature (wontfix)
ui-menu widget configurable delay
Reported by: | Edmund | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | none |
Component: | ui.menu | Version: | 1.10.0 |
Keywords: | Cc: | ||
Blocked by: | Blocking: |
Description
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?
Thanks
Change History (3)
comment:1 Changed 10 years ago by
Resolution: | → wontfix |
---|---|
Status: | new → closed |
comment:3 Changed 6 years ago by
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 :)
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.