Summary:
Change all member variables to the form m_fooBar because it is the preferred form in Qt (it was half and half between this and mFooBar, and a minority didn't have anything).
Place all references and pointers on the side of the type since it is the majority.
Basically:
- mFoo -> m_foo
- foo -> m_foo (if it is a member variable)
- Type &ref -> Type& ref
- Type *ptr -> Type* ptr
Reviewers: #kde_connect, nicolasfella, albertvaka
Reviewed By: #kde_connect, nicolasfella, albertvaka
Subscribers: albertvaka, #kde_connect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D7312
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
BUG: 370919
KWayland provides a FakeInput interface which KWin as a compositor
supports. This can be used to fake input events on Wayland. As it's
a KWin specific interface it won't work with other Wayland compositors.
If the compositor does not support the required interface, the
module just doesn't do anything. Support in the implementation is
completely optional.
Adding fake input events circumvents the Wayland security model.
Because of that the interface is designed in a way that the security
decision can be done by the compositor and can be delegated to the
user.
On first input event kdeconnect tries to "authenticate" with the
compositor. This gives the compositor the possibility to e.g. ask
the user whether it should be allowed. It's not done on startup or
of load module as that would show such a message way to early and
the user would not be able to connect it with his action on the
smartphone.
REVIEW: 124238
Don't open a second Display, we can use the one used by Qt.
Advantages are: we are on the correct Display, we don't open a Display
connection on e.g. Wayland (it would succeed but not work as a connection
to Xwayland would be opened) and we can drop the copy of fixx11h.
It's also a prerequisite to properly split the implementation to support
Wayland in a later change.
REVIEW: 124230
