Mapping of (built-in) hardware keyboard keys as modifiers

[green-green-avk]

...

May be we need also to think about possible remapping Alt and mapping Ctrl and Insert somewhere?

I do not mind about losing Insert or even Alt, but having Ctrl is crucial, and (at least in Vi) it can also compensate for other missing keys (Esc: Ctrl-C, Tab: Ctrl-I).
Some way of mapping physical keys or buttons to PC keys would be perfect, even when only over a textual configuration file. The Key Mapping Editor might already support this, but I am currently unsure how to use it, more documentation about it could help.
One should be able to map at least Volume-Up, Volume-Down and Back (should be present on many devices), ideally also the hardware keyboards' exotic keys ("Search", "Chat", web (sic!) and OK keys here) by entering their key code.
I won't push it 😉 by asking for the Menu button which is probably almost nowhere else to be found nowadays, or for the Power and Home ones which IIRC need convoluted tricks...

Originally posted by @guillaume-d in #11 (comment)

...
Here you are then:

• "Search" is KEYCODE_SEARCH
• "Chat" outputs nothing at all in the IME Test app, but directly opens the stock Messaging app, so that one key is probably hopeless
• web: same as above (opens the stock web browser app)
• OK is KEYCODE_DPAD_CENTER
• ...and Menu is KEYCODE_MENU as one would expect

(Please tell me if you'd need more logs from the IME Test app.)

However listing each and every physical key Android ever defined for mapping in the UI might be too much given the few users concerned.
(Note that the other apps listed in #10 all do something similar but all leave out some keys that nobody claimed, and their UI is already pretty crowded.)

As said in #11 (comment) a more generic solution might be more appropriate: I for one would not mind having to install IME Test and copy part of the results from there during the initial configuration to get my own keys working.

Originally posted by @guillaume-d in #11 (comment)

[guillaume-d]

Would you accept a PR for this? (I do not have anything ready yet, I have just looked at the code and I have at least some ideas how to proceed.)

I doubt I would have enough time (and expertise ATM) to do the UI for it, but I could at least contribute support for a separate configuration file for the key mappings, which could be manually edited (or copied to the right place) inside the app.
That way also the additional maintenance burden for built-in hardware keyboard support would be minimal.

[green-green-avk]

Hmm... A day or two and I could provide some preliminary solution to extend with a PR.

[green-green-avk]

Please, test: https://github.com/green-green-avk/AnotherTerm/releases/tag/%2312-1
The UI is in global settings.
If you want to pass a key around IME (Ctrl can be sensitive to it in some old devices) just map it to itself (there was a hardcoded rule for Ctrl before).

• "Turn off" means "Completely mute a key";
• "Don't use as a terminal modifier" means "Bypass as is and use to determine the final key code only" (this option is for modifiers only).
  In your case you need to map Fn (Left Alt) as "Don't use as a terminal modifier".
  All other keys - as you wish. Yes, technically you can map even your Back button.

[green-green-avk]

And yes, I'll finally fix the settings UI drop down lists rendering just a bit later.

[green-green-avk]

Fixed: https://github.com/green-green-avk/AnotherTerm/releases/tag/%2312-2

[green-green-avk]

https://github.com/green-green-avk/AnotherTerm/releases/tag/MkIIIv9_release

[guillaume-d]

TL;DR: I cannot test MkIIIv9 because the Hardware keys mapping view's text takes too much screen space.

If I force the orientation to be portrait(*), I can see the + button, add a mapping and just barely see the added mapping line. Modifying the line afterwards is practically impossible.
(*): Sliding the keyboard open forces landscape orientation here, but I'd like to map keys on the keyboard too, so I had to force portrait using a rotation manager app.

With landscape orientation, the + button is not even visible.

Maybe the help text could be made accessible over a ? button like in the Key Mapping Editor or Scratchpad views?

Anyway thanks a lot again for working on that, I really appreciate it! 👍

[green-green-avk]

https://github.com/green-green-avk/AnotherTerm/releases/tag/MkIIIv10_release
Corrected.

[guillaume-d]

In MkIIIv10 the Hardware keys mapping view's layout got a bit more usable, but mapping to modifier keys should IMHO be tweaked:

The layout still has a few problems (both landscape and portrait orientations):

• long "mapping target" labels (MOVE HOME, MOVE END, PAGE UP, PAGE DOWN) are initially truncated in the popup menu
• once one of these long labels are selected, the screen space taken never shrinks even after selecting a shorter label, thereby making the trash can icon invisible => the mapping cannot be deleted anymore
• also the sorting order used when mappings are added is not user-friendly (keycode-sorted?): maybe sort by the mapped key's label?

Ideas:

• maybe just use shorter labels: HOME, END and to a lesser extent PG UP, PG DN are pretty self-explanatory by (English (laptop)) keyboard standards.
• the right arrow glyph on each mapping line could be smaller also in these cases (the unconstrained size is pretty big)
• in landscape mode the margins/paddings between the settings tabs on the left and the actual mapping UI could be narrower

Apart from those issues, the layout stays usable even when defining a lot a mappings: there are still a few (scrollable) lines of help text, and the mappings list is scrollable too, well done! 👍

All in all I could map all special keys of the built-in keyboard and almost all Android standard keys (including Menu, but neither Home nor Power as expected) that AnotherTerm labels as External: hooray! 👍

However IMHO keys that are mapped to modifier keys like Ctrl should not need to be held while hitting the modified key: it makes typing rather hard and I think no other terminal app behaves like this.

[green-green-avk]

Hmm... What's better: either release a toggled modifier on a first regular key press or not?

BTW, there is no reliable way to distinguish a built-in and an externally connected input devices until API 29.

[guillaume-d]

Maybe a double press on a modifier key should hold it, and a single press afterwards should release it (like Android does for Shift, and like jackpal's Terminal Emulator does for Shift and Ctrl)?

If that is too much to implement, maybe rather release the modifier after the 1st regular key, but fans of Emacs keybindings may differ... Also for Shift it could probably be the opposite, like some other lesser Android terminal apps do IIRC.

On detecting built-in keyboards: maybe yet another preference flag is needed then... :-/

[green-green-avk]

Possibly intermittent variant as settings UI has definitely required to be fixed:
https://github.com/green-green-avk/AnotherTerm/releases/tag/MkIIIv14_release
"🔒¹" - unsticks on first non-modifier key.
"🔒" - just toggle.
A modifier doesn't stick at all if it's still held when a non-modifier key is pressed.

[guillaume-d]

Tested MkIIIv14 (after MkIIIv13), the settings UI is almost perfect now 👍, and I am happy already only with "Ctrl🔒¹".

However:

• [minor nit:] in the settings UI I still find the key mapping sort order confusing
• the "lock indicator overlay" should IMHO be much less distracting, a smallish icon to the top right like when hitting Ctrl+I is maybe enough if there is a legend for the icons in the help somewhere
• if it is not too much to ask I'd love to have "Ctrl🔒¹/×2🔒" so to speak (see my previous comment)

Anyway feel free to close this bug already, AnotherTerm finally reached feature-parity with the GNURoot Debian app: I can at last delete the latter and use your nice app instead! ☺️

[green-green-avk]

* [minor nit:] in the settings UI I still find the key mapping sort order confusing

Just alphabetic sort order or something more button class related?

* the "lock indicator overlay" should IMHO be much less distracting, a smallish icon to the top right like when hitting `Ctrl+I` is maybe enough if there is a legend for the icons in the help somewhere

* if it is not too much to ask I'd love to have "Ctrl🔒¹/×2🔒" so to speak (see my previous comment)

https://github.com/green-green-avk/AnotherTerm/releases/tag/MkIIIv15_release?

Anyway feel free to close this bug already, AnotherTerm finally reached feature-parity with the GNURoot Debian app: I can at last delete the latter and use your nice app instead! relaxed

Thank you.

[guillaume-d]

* [minor nit:] in the settings UI I still find the key mapping sort order confusing

Just alphabetic sort order or something more button class related?

Any sort would help, but sorting by the hardware key's label would be the most useful IMHO as said in #12 (comment).

* the "lock indicator overlay" should IMHO be much less distracting, a smallish icon to the top right like when hitting `Ctrl+I` is maybe enough if there is a legend for the icons in the help somewhere

* if it is not too much to ask I'd love to have "Ctrl🔒¹/×2🔒" so to speak (see my previous comment)

If only Fn when emulating Alt could behave the same as described above, or at least do not need holding before pressing the modified key, Another Term would have the best keyboard mapping ever seen on Android! 🤞
(Sorry I did not mention that earlier, it only became apparent when using the app for real dev tasks.)

https://github.com/green-green-avk/AnotherTerm/releases/tag/MkIIIv15_release?

The "lock indicator" is now much less distracting but still noticeable, I like it! 👍

[green-green-avk]

BTW, feel free to leave some comment here: #5 if you have some objections. November is coming.