View Issue Details

IDProjectCategoryView StatusLast Update
0004065MMW v4Otherpublic2009-02-20 03:46
ReporterLudek Assigned To 
PriorityimmediateSeverityminorReproducibilityalways
Status closedResolutionfixed 
Product Version3.0 
Fixed in Version3.1 
Summary0004065: Single Key Hotkeys are active when editing
DescriptionAs 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 InformationProbably 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.
TagsNo tags attached.
Fixed in build1199

Relationships

duplicate of 0004089 closed Single-key hotkeys cause problems 
related to 0003280 closedjiri simple hotkeys can interfere with textbox editing (e.g. can't search artists with a space) 
has duplicate 0004305 closedrusty Shortcuts are Triggered in Edit Mode 
related to 0004605 closedLudek Regression in build 1164: Can't use Del key when editing main track window column 
related to 0003223 feedbackrusty search box actions should be available in hot key 
related to 0005268 closedLudek Alt Gr button doesn't work properly 
related to 0005281 closedLudek Single key hotkeys are active in Searchbar (regression) 
related to 0006138 closedLudek 'Enter' doesn't activate menu items 
related to 0006217 closedLudek Some shortcuts are inactive while editing or typing into search bar (regression) 
related to 0006785 closedLudek Video: Fullscreen Mouse gestures and keyboard shortcuts not available 
related to 0009219 closedLudek Hotkeys shouldn't work when modal dialogs are open 

Activities

Ludek

2007-12-03 12:56

developer   ~0012262

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)

jiri

2007-12-03 13:10

administrator   ~0012263

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.

rusty

2007-12-06 17:38

administrator   ~0012321

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.

petr

2008-03-18 12:57

developer   ~0013359

Last edited: 2008-03-18 16:24

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.

Ludek

2008-03-18 13:11

developer   ~0013360

Last edited: 2008-03-18 13:12

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.

jiri

2008-03-18 18:39

administrator   ~0013364

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, ...

Ludek

2008-03-18 18:58

developer   ~0013366

Last edited: 2008-03-18 19:02

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.

rusty

2008-03-19 01:15

administrator   ~0013374

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.

jiri

2008-03-19 09:18

administrator   ~0013378

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).

Ludek

2008-03-19 12:04

developer   ~0013379

Last edited: 2008-03-19 12:10

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)

rusty

2008-03-19 13:38

administrator   ~0013381

Last edited: 2008-03-19 13:40

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.

jiri

2008-03-19 15:10

administrator   ~0013385

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.

rusty

2008-03-26 21:15

administrator   ~0013495

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.

jiri

2008-03-26 22:05

administrator   ~0013496

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.

rusty

2008-03-27 14:44

administrator   ~0013503

Last edited: 2008-03-27 14:46

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.

Ludek

2008-03-28 12:39

developer   ~0013519

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.

jiri

2008-03-28 13:02

administrator   ~0013520

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.

Ludek

2008-09-17 11:10

developer   ~0014597

Last edited: 2008-09-18 12:02

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.

rusty

2008-12-01 20:42

administrator   ~0015277

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).

rusty

2008-12-01 22:10

administrator   ~0015282

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).

Ludek

2008-12-02 10:46

developer   ~0015288

Last edited: 2008-12-02 10:47

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.

stephen_platt

2009-02-20 03:46

developer   ~0016784

verified 1223