Summary: It's not only used by the plasmoid any more but also SFOS and the app use it.
Test Plan: Builds, App runs fine
Reviewers: #kde_connect, piggz, apol
Reviewed By: #kde_connect, piggz, apol
Subscribers: piggz, kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D14567
Summary:
The RemotecommandsPlugin lacks a graphical frontend.
Inlcudes a Dbus Interface for fetching the commands and a Model exposing them to QML. For this I oriented on the NotificatonsPlugin.
Test Plan:
Open command list in app, check available commands, trigger some. Do same for CLI.
Activate edit action, check KCM opening on remote device, add command, check for new command in list
Reviewers: #kde_connect, apol
Reviewed By: #kde_connect, apol
Subscribers: apol, kdeconnect, #kde_connect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D13503
Creates a tiny messaging app that uses KPeople to query the contacts and
KDE connect telephony plugins to send plugins.
To be ready, still needs some work on the contacts sync side and some
messages history would be nice.
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
Makes it possible to display it and modify it
Introduces a DBusProperty component that can be used if we don't want
to go through the QtDBus property generation hell.
Ported using KDELibs4Support, for a smaller delta, so we can keep
developing on master until we decide not to.
At the moment, it builds and installs but tests don't pass because
of a QCA2 initialization problem I didn't manage to debug yet.
CCMAIL: kdeconnect@kde.org
Due to bug occured in QML property access(when object derived from QDBusAbstract interface) C++
part of BatteryPlugin in plasmoid rewritten in pure QML.
BatteryPluginDBusInterface fixed to avoid this bug.
Bug occuring when QML try to access any property of any object derived from
QDBusAvstractInterface - QML engine crashes.
