https://bugs.kde.org/show_bug.cgi?id=370919
Aleix Pol <aleix...@kde.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Latest Commit| |https://commits.kde.org/kde
| |connect-kde/040ad7357b5a630
| |f2fffface6a29d1be5103c663
Status|UNCONFIRMED |RESOLVED
--- Comment #13 from Aleix Pol <aleix...@kde.org> ---
Git commit 040ad7357b5a630f2fffface6a29d1be5103c663 by Aleix Pol, on behalf of
Holger Kaelberer.
Committed on 10/01/2017 at 20:12.
Pushed by apol into branch 'master'.
kdeconnect-kde: Add remotekeyboard plugin
Allow to inject keypress events to remote peers (most notably Android devices)
Notes / open issues / possible improvements:
- For the json-payload I used the syntax of the key-events as sent by
mousepad-plugin with the addition of a "sendAck"-flag. If "sendAck" is set to
true the remote peer should echo a key-event if it could be handled, thus
allowing the local client to find out whether the key was accepted. For
performance reasons, it's allowed to send multi-char strings in the "key"
property (performs much better if you send a whole string via "echo '...' |
kdeconnect-cli ..." e.g.)
- kdeconnect-cli: For now takes a string and transforms it into single
key-events for visible characters only. In a first implementation I used a
kbhit() helper that used termios.h to catch and relay keypresses interactively
(including some special-events), which was not optimal. A better approch might
be to use linux input-api directly. Would this be an option regarding
cross-platform compatibility or can I assume to develop for Linux only? Being a
command-line guy, I'd really like to have a fully featured kdeconnect-cli
interface ;-)
- Factor out the Qt::Key-to-internal keymap to some core-helper because it
corresponds to the mapping in the mousepad-plugin?
- The plasmoid is not perfect as it is: A single line containing a non-echoing
TextField (i.e. it eats all the KeyPress events), and only ack-ed
keypress-packets from the peer device are injected if they contain visible
keys. Advantage: the user sees whether his key-presses are accepted by the peer
device. Disadvantage: The echoed text does not correspond 1:1 to what is shown
on the peer's display, user might be confused when typing without success. I
played around with different variations each of which with its proper
shortcomings:
1. An echoing Textfield for typing: Has the advantage that the user can
directly see what he is typing, which makes interaction in the typing field
easier, BUT messes up interaction if the Editor on the peer is changed silently
and does not notify the user if his keypresses are not handled by the peer.
2. A non-echoing TextField for typing PLUS a readonly one for printing visible
echoed keys. Disadvantage: same as for the previous one and uses more space on
the plasmoid.
Comments? Ideas?
REVIEW: 129727
M +20 -0 cli/kdeconnect-cli.cpp
M +1 -0 interfaces/CMakeLists.txt
M +7 -0 interfaces/dbusinterfaces.cpp
M +10 -0 interfaces/dbusinterfaces.h
M +9 -0 plasmoid/declarativeplugin/kdeconnectdeclarativeplugin.cpp
M +60 -0 plasmoid/package/contents/ui/DeviceDelegate.qml
A +71 -0 plasmoid/package/contents/ui/RemoteKeyboard.qml [License:
GPL (v2/3)]
M +1 -0 plugins/CMakeLists.txt
M +1 -1 plugins/mousepad/kdeconnect_mousepad.json
A +8 -0 plugins/remotekeyboard/CMakeLists.txt
A +23 -0 plugins/remotekeyboard/README
A +28 -0 plugins/remotekeyboard/kdeconnect_remotekeyboard.json
A +144 -0 plugins/remotekeyboard/remotekeyboardplugin.cpp [License:
GPL (v2/3)]
A +65 -0 plugins/remotekeyboard/remotekeyboardplugin.h [License: GPL
(v2/3)]
https://commits.kde.org/kdeconnect-kde/040ad7357b5a630f2fffface6a29d1be5103c663
--
You are receiving this mail because:
You are watching all bug changes.
