View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004065 | MMW v4 | Other | public | 2007-12-03 12:34 | 2009-02-20 03:46 |
| Reporter | Ludek | Assigned To | |||
| Priority | immediate | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 3.0 | ||||
| Fixed in Version | 3.1 | ||||
| Summary | 0004065: Single Key Hotkeys are active when editing | ||||
| Description | As described here http://www.mediamonkey.com/forum/viewtopic.php?t=23101 there seem to be a critical issue, I guess that Dale has already reffered to this fact somewhere in Mantis: "mapped Space bar to Play/Pause now I can't enter a space when I'm editing a tag (inline or even in file properties), instead the music pauses or resumes" Hotkeys should not be applied when editing fields around the product. I guess that we could somehow handle the event of blinking cursor. | ||||
| Additional Information | Probably Rusty should prioritize this and Petr should try to find out whether there is an easy way how to find whether the text mouse cursor is blinking. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1199 | ||||
| duplicate of | 0004089 | closed | Single-key hotkeys cause problems | |
| related to | 0003280 | closed | jiri | simple hotkeys can interfere with textbox editing (e.g. can't search artists with a space) |
| has duplicate | 0004305 | closed | rusty | Shortcuts are Triggered in Edit Mode |
| related to | 0004605 | closed | Ludek | Regression in build 1164: Can't use Del key when editing main track window column |
| related to | 0003223 | feedback | rusty | search box actions should be available in hot key |
| related to | 0005268 | closed | Ludek | Alt Gr button doesn't work properly |
| related to | 0005281 | closed | Ludek | Single key hotkeys are active in Searchbar (regression) |
| related to | 0006138 | closed | Ludek | 'Enter' doesn't activate menu items |
| related to | 0006217 | closed | Ludek | Some shortcuts are inactive while editing or typing into search bar (regression) |
| related to | 0006785 | closed | Ludek | Video: Fullscreen Mouse gestures and keyboard shortcuts not available |
| related to | 0009219 | closed | Ludek | Hotkeys shouldn't work when modal dialogs are open |
|
|
I found the bug where Dale has already mentioned it: 0003280 : simple hotkeys can interfere with textbox editing (e.g. can't search artists with a space) |
|
|
I think that this was already discussed over IM with Rusty. It seems that for 3.0 it will be best to only consider this as user's problem, i.e. don't do anything about it. The reason is that hotkeys (at least some) need to work even if user is entering a text. |
|
|
Yes--for 3.0 we won't do anything. For the future, MM should either: 1) allow single-key hotkeys to be used EXCEPT when the user is performing some operation within another control 2) warn the user that a single-key hotkey can be problematic (similarly to how we warn users of a duplicate hotkey) The first option is preferable, but I don't know if it's realistic. |
|
|
I think possible solution can be to define AnyEditFocused property which indicates if any edit is currently focused and in case it's true, hotkeys engine could filter all keystrokes without CTRL or ALT down (if user's have focused any edit, keys without these two special keys should be managed as normal input). CTRL+Space can be managed in similar way in case mask edit is currently focused : if any hotkey action have assigned CTRL+Space, run this action but don't stop it to forward to another controls. |
|
|
The Petr's proposal doesn't seem to be bad and is similar to what I originally proposed, but could interfere with the Jiri's indication: " The reason is that hotkeys (at least some) need to work even if user is entering a text." Jiri should give an example of such a hotkey in order to ensure that it is not a single hotkey. |
|
|
It seems to me that the only really user-friendly approach is to warn (and don't allow?) user when a hotkey that can cause problems is assigned in Options dialog. The reason why I believe this is the best approach is that e.g. single letters aren't usable as shortcuts almost anywhere in MM. They certainly can't be used in edit controls, but even when user doesn't edit anything, there keys are often used for incremental searches etc. So, I'd propose to show something like 'This hotkey cannot be used, because it interferes with other standard Windows hotkeys' (Rusty to specify the exact wording). This applies to: 1. all single letter keys ('a', 'b', ..., '1', '2', ..., '-', '+', ...). Note that there can be also Russian, Hebrew or Chinese letters, i.e. there should be somewhat generic code used for this purpose. (or in case 2. is implemented as suggested, it's easier, only F keys would be allowed) 2. Probably all other single keys except for F1,...,F12 (or more if supported by keyboard) 3. Some common Windows shortcuts, like Alt+Tab, Ctrl+Esc, ... |
|
|
This bug was originally raised on Space bar key that is commonly used by many program / sequencers to execute Play/Pause action. I still think that this should be possible to configure without any warning and allowing to use space also when typing. Therefore I tend to Petr, i.e. to define AnyEditFocused property in order to be able to enter a space when editing/typing. Also Rusty think that this option (1) is preferable, but true is that 2) - also proposed by Jiri in previous note is preferable for single letters. |
|
|
I would suggest taking the first approach (disable single key hotkeys when controls are in focus for which single keys have meaning e.g. edit control, search bar, tree, etc....) since this is something that can be implemented right away. Later on we can add a warning, if it proves necessary. |
|
|
Well, the main problem of this is that single key hotkeys have some sense almost _always_ in MM - user is either in edit line (search, Properties, etc.) or the main window, where either tree, tracklist or NP has focus and each of these have incremental search implemented. I.e. there is only a very small number of exceptions where single key hotkeys would actually work (like About box). So, the suggested solution would work, but in a pretty confusing way from user's point of view. That's why I suggested another way (which has the problem of new string needed - i.e. can only be in MM 3.1). |
|
|
Well, but this topic is "Single Key Hotkeys are active when editing" and this is the problem from my perspective. Warning users is not so critical to me and is quite different issue. i.e. Hotkeys should not take any effect when typing, e.g. in edit control, search bar etc. , but they should override the incremental searching (like tree, NP) although this is a partial problem only for a single-letter hotkey - not space bar. I guess that almost each application does not apply hotkeys when typing to a box (i.e. when cursor blinks) |
|
|
Here's the 'Order of operations' that I was thinking of: 1) Default Windows Behaviour e.g. Alt-Tab, CTRL-C, Text appearing in dialog/textbox 2) Default MM Behaviour e.g. Quicksearch in Tree/Tracklist/NowPlaying 3) Defined hotkey behavior Here's a table that shows how this would actually play out i.e. which operation would take place in various scenarios: Focus Windows shortcuts 'Normal' Hotkeys Single-key hotkeys Single-key hotkeys ALT-TAB/CTRL-C etc. ALT/Shift/CTRL-Combo e.g. 'S' or 'T' Spacebar Tree 1 3 2 3 Searchbar 1 3 2 3 NowPlaying 1 3 2 3 Properties 1 3 1 3 In contrast, the order that Ludek defined (1, 3, 2), would yield the following actions: Focus Windows shortcuts 'Normal' Hotkeys Single-key hotkeys Single-key hotkeys ALT-TAB/CTRL-C etc. ALT/Shift/CTRL-Combo e.g. 'S' or 'T' Spacebar Tree 1 3 3 3 Searchbar 1 3 2 3 NowPlaying 1 3 3 3 Properties 1 3 1 3 This isn't a huge difference, but I prefer the first approach because it wouldn't cause inconsistencies in the quicksearch functionality (certain letters would work and others wouldn't) that Jiri brought up. I think that either of these approaches would be preferable to the status quo. I do agree that a warning 'warning' for a conflict between a hotkey and a default Windows or MM behavior could make sense, but that it's a distinct issue that could be implemented subsequently. |
|
|
Ok, so if I'm not wrong, the first table by Rusty is what I proposed, except for the last (4th) column. Let's think about the 4th column - it probably includes keys like Space, Down Arrow, PgUp, Del, etc., i.e. keys that aren't letters, but are single key hotkeys. However, they are still necessary in many contexts: Space, Del, Arrows, ... - they are needed in edit controls, i.e. Properties dialog and Search bar. Arrows, PgUp, ... - they are needed in tree and tracklist navigation Space - is also useful for incremental search in tree and tracklist So, I'd say that what I originally wrote is still valid, i.e. _all_ single key shortcuts should be disabled thorough MM, _except_ for F1-F12. (Note that this has some other small exceptions that could be allowed, but in order to make it simplier and consistent, I'd only support F1-F12 keys). I.e., to be clear, the 4th column should have the same values as the 3rd column according to what I wrote. |
|
|
I would agree with you that single key hotkeys (besides function keys) should be disabled as Global hotkeys, however, I think that if the user puts the player in focus, there's no reason why he shouldn't be able to use 'space' or arrows as a hotkey. Keep in mind that many apps use the spacebar for pause/play and many users want this type of behaviour. |
|
|
Well, but focus in the main window can only have Tree, TrackList, NP or Search, there isn't any concept of putting Player in Focus. So, as I wrote, pretty much anytime in MM Space or arrows have some (usually very important) meaning. I can only imagine one example where this would be usable and it's the MiniPlayer when NP is hidden. However, this is so special case in the whole MM that it probably doesn't need any special care. |
|
|
OK. So it seems that there's no real option but to prevent the user from choosing single key hotkeys, with the exception of function keys. As jiri indicated: Single keys could work as shortcuts only if: 1. We disable incremental searching (but then still they would be needed in Search bar, arrows would be needed in other controls, etc.) 2. When no list control is visible – it’s only the case of MiniPlayer without NP window – which is quite rare. -->this isn't a good solution, and we'll have to disable them in most cases. |
|
|
Further complaint on the Space key: http://www.mediamonkey.com/forum/viewtopic.php?t=27726 It looks like only the Space key is the trouble for users, because a lot of users want Space to Play/Pause as is in many other apps. |
|
|
I agree that the Space key is slightly special, we possibly could try to handle it this way (in case it's configured as a shortcut): 1. In case Tree, NP or TrackList is in focus: Handle it as a shortcut, only handle it as a space key in case there are already some keys in the incremental search buffer (which is cleaned up in about 1 second). 2. In case Search bar is in focus, always treat it as a space key, the same goes for any other edit line or writeable dropdown. 3. Probably also handle it as a space key on other control of any dialog (except for the main window), because Space has defined meaning on Buttons, Checkboxes, Lists with checkboxes, etc. Just an idea, I'm not sure it's worth all the trouble. |
|
|
Fixed for the "Space" key in build 1186. Reopened because I fix it for "Delete", "Backspace", "+", "-" keys too, because these have a similar nature as the "Space" key. Note that these hotkeys mustn't be global so that this fix takes effect. |
|
|
I tested this for the <space> key and it works well. I then wanted to have similar behavior for the 'forward arrow' and 'back arrow' keys, but I can't (the shortcut is always active). Is there any reason why we can't have the same behaviour that has been implemented for <space> for all single-click shortcuts? i.e. I think that this behavior that we implemented for <space> is always preferable to the alternative (the alternative being that the shortcut works all the time--even in e.g. search / properties dialogs--something that the user will never want). |
|
|
Per discussion with Jiri: The logic that has been implemented for <space> could be implemented for all keys except function keys. That should be fairly consistent, and would make other keys such as Arrow keys function more in a more usable manner if they are assigned as hotkeys (i.e. the hotkey will override the MM default behavior in some cases, but not all). |
|
|
Ok, seems to make sense to use this approach for all single hotkeys, because it is much better than current approach when single hotkey is always applied. i.e. all single hotkeys fixed same way as the Space key in build 1199. |
|
|
verified 1223 |
