View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0007886 | MMW v4 | Hotkeys | public | 2011-05-26 22:27 | 2012-11-19 20:13 |
Reporter | rusty | Assigned To | |||
Priority | high | Severity | minor | Reproducibility | always |
Status | assigned | Resolution | reopened | ||
Product Version | 4.0 | ||||
Target Version | 4.1 | Fixed in Version | 4.0 | ||
Summary | 0007886: Right/Left Arrow key hotkeys don't work correctly | ||||
Description | The right/left arrow keys are supposed to advance/move back playback by 5 seconds. For some reason, though, the functionality doesn't seem to work--even in cases where focus rests on a UI component that doesn't require arrow key movement. Apparently, this was introduced in build 1353. | ||||
Additional Information | http://www.mediamonkey.com/forum/viewtopic.php?f=6&t=56415 http://www.mediamonkey.com/forum/viewtopic.php?f=7&t=63251 http://www.mediamonkey.com/forum/viewtopic.php?f=1&t=64835 http://www.mediamonkey.com/forum/viewtopic.php?f=4&t=68644 | ||||
Tags | No tags attached. | ||||
Fixed in build | |||||
|
This is actually expected, since Left/Right arrows are needed in almost any control. So, there's no way to fix this. I'd suggest to remove them from hotkeys. |
|
In 1388 LEFT and RIGHT still can be assigned to hotkey. |
|
I suppose that they could also be completely prevented from the possible keys to be assignable, but this would probably be valid for many other keys as well. Leaving open as a lower priority issue... |
|
I think that they should be assignable, because there are still some controls that don't use them and in such a situations the hotkeys work. |
|
Ludek, you are right. one of examples is Full screen player. |
|
Verified left/right working in video and full screen. But when clicking on the regular player they don't work and instead work on last focused element (Media Tree in my test). |
|
I don't understand - Player doesn't get focus, does it? Then focus is still on the previous component, i.e. all keyboard input goes there. |
|
I don't know if it does, I did click on it and it didn't work. Can be closed if this isn't supposed to work. |
|
There's a fair bit of negative feedback regarding this issue. http://www.mediamonkey.com/forum/viewtopic.php?f=7&t=63251 Any ideas re. how to resolve? Ideally arrow key shortcuts should control the player except in cases where the shortcut is active in another mm window. |
|
I'm really not sure how users expect this to work, since Left&Rigth arrows have their meaning in all our focusable controls. So, we have to decide whether their assigned hot-key meaning can override the standard behavior for some/all controls. Asked in the forum for user's preference. |
|
What has changed since MediaMonkey 3 where this did work? |
|
It seems straightforward to me, but maybe I'm overlooking something: Right/Left should control the player except in instances where another control/dialog is in focus for which Right/Left takes priority. e.g. like in Excel. Right/Left always moves around the cells, except when focus is within a cell or in a dialog. |
|
As I explained above, left/right arrow has meaning in _all_ controls that are in the main window. That said, it seems that the consensus would be that left/right arrows aren't that important in table/tree controls, where horizontal scrolling can be achieved by other means (e.g. mouse). So let's modify it that left/right arrows: - have their default meaning in all edit controls (including in-place editing in tracklist/tree) - their assigned hotkey action is performed otherwise |
|
The reason why it worked in MM3 was that issues like 0007427 Left and Right arrow keys don't work in the main tree 0007371: 1348: Keyboard navigation broken in Explorer Tree (Regression) were broken in MM3. So they takes precedence now. As Jiri said, the left/right arrows are needed in almost any focusable control. The alternation could be that _both_ the actions would be performed. e.g. on right arrow: - tree node would be expanded - hotkey to skip 5 seconds forward would be performed But this is a buggy behaviour in my opinion. |
|
I'd still implement as suggested above. Note that when these keys aren't assigned, they should work in their default meaning in tree/lists. |
|
I would like to Add that we have blind users highly dependable on Arrow keys for navigation that thanked us for fixing bugs Ludek Mentioned. |