There's a menu opening bug that I'm fairly sure isn't an SMPlayer bug as such, rather it's a Qt bug, but if I'm correct I can't seem to find a way for an end user to report Qt bugs anyway, so I thought I'd report it here.
There's a registry entry for controlling the delay with which menus open. I'm using XP but as far as I know it's the same for all Windows flavours. Here's a link referring to it for Windows 10. https://www.tenforums.com/tutorials/144 ... -10-a.html
When you set a delay time, after highlighting a menu item, it's sub menu will take that amount of time to open. The idea being if they don't open instantly it's easier to click the correct sub-menu. This works correctly.
If you have a lengthy delay set though, you can open a sub-menu on demand by simply clicking on it. Therefore by setting an extremely long delay, sub-menus effectively never open until you click. That's the part that doesn't work properly. Clicking on a menu item has no effect, so you're forced to wait the entire delay time set in the registry. Initially I though SMPlayer's menu system was broken because none of the sub-menu items would open (I have a long delay set), then the penny dropped.
The above only applies to sub-menu items. The root menu items on the menu bar ignore the rules completely and open without any delay, regardless of the delay set in the registry. That might also be a Qt bug. I'm not sure.
And for some reason if you switch to a different interface, immediately after switching all menu items ignore the rules and open immediately, but after restarting the player the behaviour I've described returns.
Thanks
