[Xposed Framework Modules] Roughy:
Exi for Swiftkey 1.4.1 release

1.4.1 [ 11.04.2018 ] - Hardware key remapping, undo/redo, transparent keyboard ( Stable: 7.0.2.15, Beta: 7.0.2.14 )

Edit: No major update is complete without new bugs, so here is a list of what has popped up so far:

Keyboard transparency is reset on orientation change

These issues will be fixed in a couple of days, once any other issues have had a chance to be discovered.

Changes in [1.4.1] (Stable: 7.0.2.15, Beta: 7.0.2.14) :

Fixed

- Emoji font size setting sometimes not being applied

- Quick menu and hotkey popups not displaying correctly in floating keyboard

- Crash caused by incomplete database initialization

- Swiftkey crash when updating module without restarting device

Added

- Remappable hardware keys

- Configurable hardware key shortcuts

- Undo / Redo text actions ( Android Marshmallow and later )

- Keyboard transparency slider ( for floating keyboard)

- Option to disable support for RTL text when swipe-selecting ( for compatibility )

- Memory limit to emoji render cache

- Ability to cancel quick-menu by return finger to start location on the space bar

- Croatian translation courtesy of Dino (dugi991)

Changed

- Increased max emoji font size

- No-Punctuation auto-space now also applies to ampersand and hyphen characters

Download:

Exi for Swiftkey on Xposed module repository

Notes:

Kitkat support

Those of you still on Kitkat might have noticed that there haven't been any Swiftkey updates on a while.

It turns out Swiftkey has nixed support for Kitkat, and are now only distributing builds for Lollipop and later.

This module will always target the latest version of Swiftkey, so this means kitkat is effectively no longer supported.

As of writing most features still work fine on the last version of Swiftkey that was released with Kitkat support,

but I wouldn't expect that to go on for too long.

Undo / Redo text actions [MENTION=4303016]rolear8[/MENTION]

So it turns out android has supported undo / redo natively since Marshmallow, google just never bothered updating their documentation to reflect this change, so unless you happen to be digging through the source code you would never know.

Since this feature relies on android's native implementation, it will only be available if you are running Marshmallow or later.

Hardware hotkeys

You can now define hotkeys using physical hardware keys from a real keyboard.

When defining a hotkey you can select between two tabs: Software for on-screen keyboard keys, and Hardware for physical keyboard hotkeys:

Unlike software hotkeys, hardware hotkeys can also be triggered use single keys instead of requiring a modifier + key input.

Pretty much all of the actions available are already accessible if you have a real keyboard, so this is pretty pointless.

See below for more information on hardware keys.

Remappable hardware keys [MENTION=5962170]wokawoka[/MENTION]

You can now map any hardware key to any other hardware key, even keys that are not available on your device.

This feature is available under settings - Remapped Hardware keys.

Adding a new key, you will be presented with a dialog where you can select the key to map from, and the key to map to:

Clicking on either key, you will be presented yet another dialog where you can phyiscall enter the key you wish you map from/to:

If you wish to map to a key not available on your device, or map from a key that you cannot press without triggering some action (e.g. the power button), you can hit "Select from list" to expand a list of all key scancodes android will recognize, from which you can select the appropriate key:

Since a lot of keyboard interaction is handled outside of the IME itself, remapping is handled at the system level. That means that any remapped keys will also be remapped outside of Swiftkey.

Couple this with the fact that your power button, audio up/down buttons, and, unless you are using on-screen buttons, even the menu / home / back buttons at the bottom of the phone count as hardware keys, you can do some pretty weird things. Want to use your power button as ctrl? That'll work. Menu button as volume-up? also fine.

The complete list of available scan codes includes a bunch of keys that will likely do nothing on your particular device, but I'm sure someone will find a use for it.

There are some special cases for handling the ctrl, shift, and alt modifiers, but those are mostly transparent to the user. If you remap a key to num/caps/scroll lock, it will act independently of the physical equivalent, but sync its state if the real key is pressed.

Depending on your keyboard layout, the key detected by exi may not match the key you input. For instance, "æ" on a Norwegian keyboard emits the scancode for apostrophe, and will be displayed accordingly.

Sometimes Swiftkey will detect a physical keyboard, but not accept ctr+1 2 3 to insert the candidate unless you set it to hide the on-screen keyboard if a physical keyboard is present. On other devices it will do this automatically.

-- Emulators and Scrcpy --

Remapping keys works fine with both android emulators and remote programs like Scrcpy, but since they do not accurately transmit the users input there are some caveats.

When inputting a key using these programs, [key down] and [key up] are transmitted instantly, instead of waiting for the user to release the button. This means you cannot remap another unused key (say, A) to the ctrl key, since it will be released immediately.

The best solution to this is to remap the left-shift key to ctrl, which will let you use the left shift key as ctrl.

Ideally you would then just use your right shift key when you want to capitalize something, but unfortunately Scrcpy always transmits left-shift, even if the user is pressing right-shift.

It also does this when you have caps-lock enabled; quickly transmitting [shift-left down][a down][a up][shift-left up] if you input the letter A with caps lock enabled.

Ability to cancel quick-menu by returning finger to start location on the spacebar [MENTION=282268]Zoltair Wright[/MENTION]

Does exactly what it says it does. Return your finger to roughly the same horizontal position on the spacebar you started from and you can release it without triggering an action.

No-Punctuation auto-space now also applies to ampersand and hyphen characters [MENTION=4686530]Mohit Ghune[/MENTION]

Ampersand and hyphen are not punctuation! this is wrong! But the rules have been modified to remove the magical spaces for them too.

Keyboard transparency slider ( for floating keyboard) [MENTION=2797855]Tundraswan[/MENTION]

This was requested long ago, but making it work with a non-floating keyboard would be difficult, so it was put on hold.

Apparently supporting the floating keyboard alone is sufficient, so now that's a thing. Do note that this makes everything transparent, not just the background.

Option to disable support for RTL text when swipe-selecting ( for compatibility )

When we added support for RTL, we did so by abusing a lot of lesser known features of android.

The hacks involve greatly rely on the quirky behavior of the stock android textviews, so things may behave strangely in some non-standard implementations.

Under settings you can now disable these hacks. You lose RTL support, but gain wider compatibility. If you know you won't interact with RTL text, you might as well go disable this now.

Croatian translation

Croatian translation courtesy of Dino (dugi991) !

This translation has actually been available for quite some time, but I didn't have any other updates to push.

I would highlight them here, but I don't know if they are even on xda. Thanks!

Emoji font size [MENTION=483168]ogsho[/MENTION]

The emoji font size can now be configured all the way up to 50, which brings us well into silly-big territory.

The problem with having emoji too big is that instead of the emoji being rendered at a low resolution and upscaled,

they are rendered at the actual size they are displayed at. This means that large emoji will consume a silly amount of memory.

To counteract this the emoji cache now limits itself to 1/8th of the memory available to it, and will discard old items as necessary.

I'm actually surprised out-of-memory crashes haven't been more of an issue.

Cursor getting stuck after pasting text bug

I have spent quite a bit of time trying to reliably reproduce this bug, but have had little luck.

I think it might be limited to users who use flow, and I know it is not caused by disable-jumping-cursor, but that's all I've got.

If you do encounter it, just pulling down the notification bar or hopping over to another app real quick will reset it.

I'm 99% sure the bug is on Swiftkey's side, and some combination of the actions we are performing just happens to set it off.

Sorry, I am not going to be able to do anything about this unless I can find a way to reliably reproduce it.