#1416 Extend available keyboard shortcuts for Search window

[Kos Ivantsov]

Currently, in the Search window there are a few mnemonics used for triggering options, and a few predefined shortcuts to perform a few actions.
It would be very helpful if what is available as mnemonics (and those couple options that didn't get any mnemonics) could also be triggered by user-defined shortcuts, and a few new actions added to the window to provide for mouse-free operation.
Requested new actions:
Move focus to the field with the search results.
Go to the segment (in the Editor) of the currently active search result (similar to what is done when "Auto-sync with Editor" is enabled, but performed only when requested)

The shortcuts could be customised similarly to how it's done for the main menu and the Editor pane, i.e. through SearchShortcuts.properties

[Hb]

KEYS
Some options in the dialogs second row are lacking from a shortcut key. On the other hand some advanced options, which are initially hidden, do have a shortcut. This seems not appropriate.

Current and proposed mapping:

A Case sensitive
B Changed before
C Close
D Select Folder
E Excat search
F Files
G Glossaries
H Author --> S&how Advanced Options/&Hide Advanced Options
I In translation
J Project
K Keyword search
L Translated or untranslated
M TMs
N Untranslated
O Hide Advanced Options --> In c&omments
P Space matches nbsp (and with priority on button) Replace All
R Regular expressions (and with priority on button) Replace
S Search
T Translated
U In source
V Recursive search
W Full/half width char
X (none)
Y Memory
Z (none) --> In notes(&z)

This proposal strips the checkbox Author from its shortcut and gives shortcuts to the boxes In notes and In comments.

FOCUS
After a successful search the focus currently jumps inside the results field, is moveable by TAB and envokes the source string in the editor by ENTER. This looks fine to me.

[Kos Ivantsov]

FOCUS
After a successful search the focus currently jumps inside the results field, is moveable by TAB and envokes the source string in the editor by ENTER. This looks fine to me.

It is the case only if you use TAB to advance to the next segment, which is not necessarily everyone's preference.

[Hb]

Currently CTRL+N and CTRL+P work in the results list the same way as they do in the editor. SHIFT+TAB steps backwarks too. PAGEDOWN and PAGEUP also work and step page wise.

Which function or movement is missing?

[Kos Ivantsov]

Jumping from the results to the Editor when Enter is used to advance to the next segment.

[Kos Ivantsov]

And moving focus into search results area without performing search would still be nice, especially when one search was performed, and now the user wants to build another search query by copying pieces from different results.

[Kos Ivantsov]

Using mnemonics is fine, but if the options are triggered by only mnemonics or mouse, users who translate into languages based on non-Latin scripts, won't be able to change them using the keyboard, or, even if they will (it may depend on the OS), these won't be any hints in the actual UI to tell them which option is triggered by the corresponding key. For instance, in Ukrainian the text for the checkbox for "&In translation" will be "У перекладі", and the key with Latin "I" is Cyrillic "Ш" in most layouts. The letter "Ш" is not used in that string, so even though on some systems pressing Alt+Ш may still check or uncheck the box, it doesn't seem too effective to try to remember a random sequence of letters not reinforced by anything in the actual strings used in the UI.

[Hb]

With "Mnemonics" we mean underlined elements in the UI like this https://en.wikipedia.org/wiki/Mnemonics_%28keyboard%29 _, aren't we?

As far as I understood, the programmers offer most parts of the GUI for translation. In https://github.com/omegat-org/omegat/blob/master/src/org/omegat/Bundle.properties the actions and options are listed together with theri English labels. This file is open for translation.

So the translators can place a & character in the string of each label. The following letter gets underlined and is mapped as shortcut for this action or option.

The Ukranian UI is attached. Some labels and shortcut keys are Kyrillic. Seems fine to me.

[Kos Ivantsov]

I stand corrected. In the past non-Latin mnemonics didn't work in Java applications on Linux, so I tended to stick to English UI and up till now didn't know that things have changed .
Still, despite this very nice discovery I do think that having a consistent set of shortcuts (in addition to mnemonics, not instead of them) that would work the same regardless the UI language, would be a great improvement, and will still work in situations like we have now where there are more options than available letters.

[Hb]

Ok. What is the difference between a mnemonic and a shortcutin your view?

[Kos Ivantsov]

By shortcuts I mean key combinations with modifiers (Ctrl, Shift, Alt) and another key, that's why I suggested using something like SearchShortcuts.properties similarly to EditorShortcuts.properties or MainMenuShortcuts.properties
These shortcuts, unlike mnemonics, would remain the same with any UI language, and they could be assigned by users according to their own likings.

[Briac Pilpré]

Added a shortcut to jump to the selected search result (Ctrl+J by default) in [r10680].

[Aaron Madlon-Kay]

Released in 4.3.0.

[Aaron Madlon-Kay]

Sorry, I realized this RFE requests much more than was actually implemented. Reopening.