https://bugs.kde.org/show_bug.cgi?id=370919
--- Comment #1 from Holger Kaelberer <holge...@elberer.de> --- I've got an experimental implementation of an InputMethod on Android to inject key-events from desktop-to-mobile. After some testing and improvements it seems to work pretty well for printable keys and some selected special keys (like Backspace/Arrow-keys/Return etc) and I wanted to ask your opinion on some points, Aleix and Albert (especially because I'm not an Android programmer -- yet ;-): Some misc. remarks/questions: * InputMethod and activation: For now the InputMethodService is baked into the MousePadPlugin. As soon as installed it is visible and selectable from the IME list in the Android settings. Once selected it remains the active InputMethod until it is deselected again by the user or kdeconnect is uninstalled. That means, it remains active also if not currently paired (with a remote device that supports the plugin). For me this behaviour was fine, but I'm not sure if it should remain like that. Depending on what is possible on android we could consider to ... ... De/Activate InputMethod automatically if not paired (if possible)? ... De/activate it based on capabilities of the paired device For now keys are only accepted when the keyboard is visible (InputMethodService.onStartInputView()). I think about adding a setting to enable accepting keys always (e.g. for selecting and starting apps on the home screen with arrow-/return-keys. On the visual side the keyboard only contains one row with a settings- and a keyboard-button for entering directly the settings dialog and the keyboard selection-dialog, resp. I think about adding a isPaired indicator and maybe a Return and a Backspace key. * On-the-wire format: I experimented a bit with the structure of the NetworkPackage payload (type "kdeconnect.keyboard"). Mere transferring of printable characters turned out to be insufficient, because it would become hard to handle special keys like backspace, Shift, etc. Therefore for now the payload basically contains a QKeyEvent serialized to JSON. This carries all information necessary to handle special and modifier keys. The Qt keycodes are then mapped to KeyEvent.KEYCODE_XXX values and some selected keys are handled in a special way (like Backspace, Left, Shift-Left, Home, etc.) and result in KeyEvent sequences on the android side. One could also think about using a (single-)char utf8 payload for the keyevents, mapping (selected) special keys to (corresponding) unicode-values. But this makes serialization on desktop-side more complex, and I'd prefer to stick to the QKeyEvent way. If a keyevent was successfully delivered to the InputMethod it is reported back to the remote keyboard (if requested), to allow for visualizing what arrived on the other side. It might be useful to add additional packages to signal keyboard-activation and disable typing on a remote keyboard if it is not possible to deliver anything or/and error-reporting to notify a remote typer why his keys did not reach their destination. * Plasmoid: To the plasmoid I added a TextField for inputting the remote keys and a second readonly one that echoes the keys confirmed from the remote side. I'm not yet completely happy with that. Ideally I think of a single TextField (or TextInput) not echoing keypresses immediately but only after having been ack-ed by the remote device, thus the user can see immediately what he typed remotely. But that would mean to interpret the echoed kepress-event equivalently to what is done on the remote side. I tried to manually inject a QKeyPress via postEvent directly to the TextField but that was not evaluated by the TextField, dunno why. Also added a command-line flag to kdeconnect-cli for sending keypresses (interactively) to a remote. * Plugin: For my POC everything lives inside the MousepadPlugin on both sides. As you already factored out the sendnotifications I wonder if I should add a new plugin for this direction of the remote-keyboard feature as well? * More possibilities: Add support for defining special keys on the smartphone (e.g. F1-F10) and make them execute special actions when pressed on the remote keyboard (Press menu button, start app X, ...) * Finally: Would you be interested in accepting it in KDE Connect? Please let me know what you think about it. After these first tests it looks promising and might be a nice extension especially for computer people that hate typing on an on-screen keyboard, like me :-P Thanks, regards, Holger -- You are receiving this mail because: You are watching all bug changes.
