Search and Top Navigation
#9062 closed feature (wontfix)
Opened February 05, 2013 09:28PM UTC
Closed February 06, 2013 01:11AM UTC
Last modified March 14, 2017 06:19PM UTC
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
Attachments (0)
Change History (3)
Changed February 06, 2013 01:11AM UTC by comment:1
| resolution: | → wontfix |
|---|---|
| status: | new → closed |
Changed February 10, 2013 10:41PM UTC by comment:2
| _comment0: | Ok thanks a lot for the response. \ \ → 1360536139860808 |
|---|
Ok thanks a lot for the response :)
Changed March 14, 2017 06:19PM UTC by comment:3
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.