* Add section mark as an extra key in QWERTY-like layouts that don't have it already
* Add dagger (also double dagger) as an extra key in QWERTY-like layouts
This is a new section in the extra keys option that allows to enter
arbitrary strings which are then added to the keyboard.
A new string is needed for the title of the section, Android's icons and
strings are used as much as possible to avoid adding more strings.
Keys are stored in the preferences as a JSON array of strings.
The current approach is hard to maintain, for example the last key
"autofill" was not displayed.
This implements a PreferenceGroup that contains the check boxes for
every extra keys without involving listing the preferences in
settings.xml.
A custom layout is used to remove the 'title' text view.
The list of extra keys is moved into the new class.
'ExtraKeyCheckBoxPreference' becomes a nested class.
`gen_layouts.py` lists the layouts in `res/xml` and generate the
`pref_layout_values` and `pref_layout_entries` arrays into
`res/values/layouts.xml`.
These arrays are hard to maintain as the order has to match, which is
fragile.
This relies on every layouts having a `name` attribute.
Added Romanian characters to the keyboard layout and changed the positioning
corner for the secondary characters that were conflicting with the
newly-introduced romanian characters
Added Romanian translations
The new key switches to any installed "voice" input method.
If several input methods matches, no effort is made to choose.
Might misbehave with some input methods other than Google's on API < 28.
It is placed on the middle of the arrows on the bottom bar. It is
enabled by default and can be removed in the "Extra keys" option.
The key is not removed from the keyboard if no voice input method
exists.
The newer haptic feedback API that is used instead of the vibrator
service since ef03dfe doesn't work for everyone.
The new vibration option allow to choose both the newer API ("system")
and the older API ("strong", "medium", "light").
'Keyboard.Key' now contains an array of size 9, giving each keyvalue an
index. The algorithm for finding the nearest key during a swipe now
needs 16 segments, which are now calculated as an angle.
The algorithm does one more interation instead of 2 more, slightly
reducing the sensitivity of corner values. The 'getAtDirection' function
is moved into the Pointers class to clearly separate the two systems.
The 'edgekey' attribute is now obsolete but is kept for compatibility.
The flag is removed internally, key index are simply translated.
Similarly, the 'slider' attribute now act on keys at index 5 and 6
instead of 2 and 3.
A new option changes the "change_method" into the new
"change_method_prev". It switch to the previously used input method.
A long press on "change_method_prev" sends "change_method".
A new section is added in the settings and existing options are moved.
Send key events for the left or right arrow as the finger slides on the
space bar.
Can be used to select text by holding shift. Works under Termux.
Events are sent linearly as the finger travels. The distance between
each events is defined from the swiping distance divided by 4.
'slider="true"' can be set on a key that have 'edgekeys="true"'.
'key2' and 'key3' represent the right and left keys.
It allowed to modulate the repeat speed of some keys (arrow, backspace,
delete) by move the finger farther or closer to the key.
In practice, this wasn't pratical and doesn't seem popular. It is
removed in favor of a better mechanism for moving the cursor.
The most requested keys are undo and redo. Unfortunatly redo doesn't
work reliably.
The other context menu actions like share, assist and autofill are added
even thought they are rarely useful or implemented.
* Add option for keyboard opacity (transparency). Keyboard background, keys and pressed keys can be adjusted separately.
* Make the borders transparent as well
* Moved setAlphas outside drawKeyFrame to top of onDraw method
Some users reported that 25% of the screen height is too high on their
screen. This doesn't seem to be a good way to define the height but
until it is improved, allow smaller values.
Add an option for specifying an XML layout description as a string.
The option is a bit rough at the moment:
- No documentation, users have to be aware of the keyboard's code to use
this option.
- No error are shown, the layout will fallback to qwerty on error.