I have (besides other) two keyboard shortcuts:
- 'j' is set to 'playlist search'
- 'i' is set to 'properties'

to reproduce the bug:
1: press 'j'
2: press a key which is not assigned to a shortcut
3: press 'i'

expected result: the letter 'i' should be shown in the search field

actual result: the properties dialog is shown

this works for all letters with assigned keyboard shortcuts

edit: using XP Pro SP2

From the release notes:

Known / not exactly a bug.

If I understand this correctly, my single letter keyboard shortcuts should have been removed upon installation of 0.9.5b1?

If the answer is 'yes', then I can report, that this was definitely not the case for me when I upgraded from 0.9.4.5. The reason could be, that I had a crash related to foo_uie_albumart the first time I started 0.9.5b1



edit: typos...

Hello,
This also happens for me. I was using version 0.9.4.5 with quite large list of single letter keyboard shortcuts. Upgrading to version 0.9.5 beta1 did not removed these keys. More over I would rather like to have them acceptable for 0.9.5 final. Has it been already decided that such shortcut keys won't be allowed? If yes then... Is it fixed and is there a way to reconsider it?

Hi,

I've got one fb2k setup with lots of "1-key" keyboard bindings (r=restart, h=hide window etc..). foo_facets, to be precise it's search textfield, is the first component which doesn't work with these. E.g. when I try to type "r" into the textfield, foobar restarts.

OK, we can discuss if 1-key bindings are necessary or if the user expresses his wish, to have the key binding always be matched.

But it's the first component which does react in this way. All other text fields, fb2k core and components text fields (like in foo_uie_quicksearch) do not execute the key binding but simply let you type into.

What do you think, Frank?

TIA

EDIT:
Exactly the same happened here/ is my opinion. I'd also like to keep my single letter shortcuts.

@Squeller:

I have merged your post with this thread that already explains the situation.

At least I can see single key shortcuts work if ui!=default ui.

I can't understand why the keyboard shortcuts behavior was changed, restricting the use of a shortcut without modifiers. Anyone care to explain please. It was better in 0.9.4 imo.

Not exactly. For example, in the Edit -> Search window they don't (even though this window was invoked from Columns UI).

If it is not too late, please consider allowing single key accelerators. They are a very important part of usability.

Hey Halabund,

I didn't test but read properly. Single keys are not recommended, but allowed according to the changelog.
You just need to add them again. I think single keys won't be a problem here as I use columnsUi.

They are a problem in the Edit -> Search dialogue box. The actions associated with them are triggered even when one is typing in a text box. For example, I set "J" to bring up foosion's Databse Search window. Now I cannot type "j" in the search dialogue box, even though I use Columns UI.

I'd really like to see this fixed, at least in parts of the Default UI which are accessible from other UIs too (like Edit -> Search).

actually for me it would be enough if the single global shortcut keys were working in the playlist view, embedded album list treeview and listview, embedded equalizer window and any of the tabs. In the subdialogs it does not make sense at all as well as in the edit fields.

Well, that's exactly the point! That's how it was in previous versions: they only worked where it made sense, i.e. not in textboxes.

I also preferred the previous behaviour. That is, single key shortcuts functioned where they did not override any keyboard functionality provided by the currently focused control. To provide examples:

• All single key shortcuts except space, enter and up and down arrows should work when focused on the playlist itself.
• All single key shortcuts except left and right arrows should work when focused on any of the tab controls. (Left and right arrows move between tabs.)
• Single key shortcuts should probably not work when focused on the album list controls, as I suspect these allow for movement to items by typing letters. Arrow keys should definitely not be overridden here.
• No single key shortcuts should work in edit fields.
• No single key shortcuts should work outside of the main window.

The new behaviour makes operation via the keyboard alone a little tedious at best.