Summary: It is functional on the desktop as well and provides a place for controls for desktop to desktop features (e.g. MprisRemote, LockPlugin) and controls for non-Plasma desktops (e.g. Remotekeyboard, not yet implemented)
Test Plan: Builds
Reviewers: #kde_connect, apol, sredman
Reviewed By: apol
Subscribers: piggz, apol, sredman, kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D15399
Summary: This plugin sends a request for a photo to the connected device. The device then sends the photo back, currently via the SharePlugin.
Test Plan:
kdeconnect-cli --photo
Check for photo in Downlaods folder
Reviewers: #kde_connect, broulik, albertvaka
Reviewed By: #kde_connect, albertvaka
Subscribers: sredman, albertvaka, apol, ngraham, kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D18140
Summary: Added primitive support for the mpriscontrol plugin on Windows by simulating VK_MEDIA key presses. I took a look into `ISystemMediaTransportControls`, but there doesn't seem to query it since it's per app. Leaving simulating key presses our only option for now. Completes T10000
Reviewers: kdeconnect, #kde_connect, albertvaka
Reviewed By: #kde_connect, albertvaka
Subscribers: albertvaka
Tags: #kde_connect, #windows
Maniphest Tasks: T10000
Differential Revision: https://phabricator.kde.org/D17702
Summary: I've added Windows support to the systemvolume plugin.
Test Plan: Move the volume sliders in the Android app
Reviewers: kdeconnect, #kde_connect, albertvaka
Reviewed By: #kde_connect, albertvaka
Subscribers: albertvaka, kdeconnect
Tags: #kde_connect, #windows
Maniphest Tasks: T10000
Differential Revision: https://phabricator.kde.org/D16936
Summary:
Added windows support to the runcommand plugin
Completes T10001
Test Plan:
1. Run a command
2. Run the command
Reviewers: #kde_connect, nicolasfella, albertvaka
Reviewed By: #kde_connect, albertvaka
Subscribers: albertvaka, shivanshukantprasad, apol, nicolasfella, kdeconnect, #kde_connect
Tags: #kde_connect, #windows
Differential Revision: https://phabricator.kde.org/D16746
Summary:
Main change is to use libkeepalive to wake up the system to ensure connections stay alive
Other minor changes are:
-Log daemon messages for debugging purposes
-Add way to forece refresh of device list
-Minor spec improvements
The keepalive changes certainly seem to help, not sure if it completely solves the problems
The logging changes are temporary, and I could use them locally, but they only affect sailfish users
Im not sure if the refresh method is correct, but seems to force the daemon to check for devices
Reviewers: #kde_connect, nicolasfella, albertvaka
Reviewed By: #kde_connect, albertvaka
Subscribers: kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D15414
Summary:
Telephony and SMS handling are quite distinct so they should be in separate plugins for better maintainability, given that @sredman has big plans with SMS.
This diff should be fully backwards compatible, but whether we really want to do that is up to discussion
Test Plan: Only supeficially tested. Receive an SMS (old way), Notification is shown
Reviewers: #kde_connect, sredman
Reviewed By: sredman
Subscribers: albertvaka, apol, sredman, kdeconnect, #kde_connect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D13594
Summary:
Below is a lost of the commits, but, in summary
Port the build system for Sailfish, which means selectively building only the bits we need/can, and only against the KF5 libs that are available.
Allow to build on Qt 5.6
Switch from knotification to nemo notification (not complete!)
Add a very simple example sailfish app.
Note, there is still much missing functionality. Notifications dont work, pairing sort of works but not really, but when it is paired you can send a ping to the desktop client
Dont build kio for Sailfish
Port core build system
Port daemon buld system
Require CoreAddons on Sailfish
Port plugins build for sailfish and include the ping plugin for now
Final build changes for sailfish.
Disable tests and other not needed parts
Add includes for QCA
Fix build errors on sailfish
Get core/ to build on sailfish
Get interfaces/ to build on sailfish
Build daemon on sailfish
On sailfish, dont install the kcm file
Start port plugin to sailfish
Fixup installed files
Add sfos app
Hack declarative plugin to give a public interface
Build sfos app
Compile declarativeplugin into the sfos app for now
Redefine qAsConst for qt 5.6
Packaging fixes
Use official icon
Package .desktop
Reviewers: #kde_connect, apol, nicolasfella, albertvaka
Reviewed By: #kde_connect, apol, nicolasfella, albertvaka
Subscribers: kdeconnect, andyholmes, albertvaka, kossebau, mtijink, vonreth, apol, #kde_connect, nicolasfella
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D10703
Summary: This plugin allows controlling the system value from a remote device.
Test Plan: Apply Android patch, open up MPRIS Activity and play with the slider
Reviewers: #kde_connect, mtijink, albertvaka
Reviewed By: #kde_connect, albertvaka
Subscribers: kdeconnect, apol, zhigalin, albertvaka, davidedmundson, mtijink, #kde_connect
Tags: #kde_connect
Maniphest Tasks: T4659
Differential Revision: https://phabricator.kde.org/D7992
Summary:
Allows other devices to make this device discoverable via a
kdeconnect.findmyphone.request command, if running.
Currently supports playing a sound.
Counterpart to FindMyPhone plugin
Test Plan:
Connect with other device running KDE Connect (with Plasmoid).
Select a working play sound in the Find My Device plugin settings.
On other device trigger Find My Phone button for this device in KDE Connect
Plasmoid and notice this device playing the configured sound.
Reviewers: #kde_connect, nicolasfella
Reviewed By: #kde_connect, nicolasfella
Subscribers: kdeconnect, sredman, mtijink, apol, nicolasfella
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D11773
Summary:
Allows other devices to make this device discoverable via a
kdeconnect.findmyphone.request command, if running.
Currently supports playing a sound.
Counterpart to FindMyPhone plugin
Test Plan:
Connect with other device running KDE Connect (with Plasmoid).
Select a working play sound in the Find My Device plugin settings.
On other device trigger Find My Phone button for this device in KDE Connect
Plasmoid and notice this device playing the configured sound.
Reviewers: #kde_connect, nicolasfella
Reviewed By: #kde_connect, nicolasfella
Subscribers: kdeconnect, sredman, mtijink, apol, nicolasfella
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D11773
Summary:
Add a plugin to KDE Connect which supports exporting the Android contacts databases to vcards on the desktop
When the devices are connected, the plugin sends a request for all timestamps and IDs
When a packet with timestamps and IDs is received, it verifies it has vcards for each ID and that the timestamps match and deletes any vcards for IDs which were not reported. It then sends a request for all vcards which were missing or need updating
When a packet with vcards is received they are unconditionally written to disk, possibly overwriting existing vcards
Provides one dbus method: contacts/synchronizeRemoteWithLocal which triggers the request for all timestamps and IDs
BUG: 367999
Test Plan:
Connect the device to the desktop and verify that vcards are created in QStandardPaths::GenericDataLocation / kpeoplevcard". On my system this is ~/.local/share/kpeoplevcard
Create a dummy contact on the device and verify it is synchronized (Currently not automatic, have to disconnect and reconnect or use dbus)
Modify the dummy contact and verify the modifications are synchronized (Currently not automatic, have to disconnect and reconnect or use dbus)
Delete the dummy contact and verify the deletion is synchronized (Currently not automatic, have to disconnect and reconnect or use dbus)
Reviewers: #kde_connect, apol
Reviewed By: #kde_connect, apol
Subscribers: mtijink, #kde_connect, apol
Tags: #kde_connect
Maniphest Tasks: T8283
Differential Revision: https://phabricator.kde.org/D9691
Summary:
Windows no longer needs a separate plugin, and X11 and Wayland are now in
separate files instead of having lots of ifdefs.
Test Plan: Tested on X11, Wayland and Windows.
Reviewers: #kde_connect, apol, nicolasfella
Reviewed By: #kde_connect, apol, nicolasfella
Subscribers: apol, nicolasfella
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D11692
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
