We use kdeconnect-version.h in several places and therefore it needs to be in the include path. We currently do this by setting target_include_path in a few places. Replace this with an interface library that we can link against that sets up the correct include path. IMO it is cleaner this way.
Qt 5.14 adds a "--help-all" option, so include it in the autocompletion.
Qt 5.14 also warns on multiple additions of the same option, which we
accidently did (KAboutData and we ourselves called it), so don't do
that.
Also fixes device autocompletion, which I accidently broke.
Main changes:
- Allow grouping single-letter options (current single letter options
are exclusive, but that might change in the future. Qt supports
parsing such groups)
- Allowing completions like "-d<id>" and "--device=<id>"
- Make operations exclusive in completion (e.g. --ping and --ring can't
be used at the same time)
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:
Devices that were reachable but not paired were not shown. This makes it impossible to initiate paring
BUG: 402088
Test Plan:
Have a unpaired device reachable. Without the patch kdeconnect-cli -l does not show it. With the patch it is shown
Reviewers: #kde_connect, albertvaka
Reviewed By: #kde_connect, albertvaka
Subscribers: kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D17788
Summary:
Can be used with the share-text argument like
kdeconnect-cli -d adsjsakldsjsa --share-text "hello"
Reviewers: #kde_connect, albertvaka
Reviewed By: #kde_connect, albertvaka
Subscribers: kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D17242
Summary:
Combine multiple upload jobs for files into a single KCompositeJob so only 1 notification will be shown
Includes changes introduced in D16279
Test Plan:
1. Share of multiple files is performed using 1 composite job
Setup:
- Select multiple (big) files in dolphin and share with an Android device
Result:
- The files will be transferred using 1 CompositeUploadJob and showing only 1 notification
2. Share of file while another share is already running adds job to existing composite job
Setup:
- Select multiple (big) files in dolphin and share with an Android device
- Share an additional file with the same Android device
Result:
- The files are all transferred using 1 CompositeUploadJob and showing only 1 notification
- The notification is updated after adding the last file
3. Other packets are transmitted as usual
Setup:
- Setup sharing desktop notification with device
- Share a big file with an Android device
- Generate a desktop notification (eg. sending or receiving an email)
Result:
- Notification packet is send immediately
Reviewers: #kde_connect, nicolasfella, albertvaka
Reviewed By: #kde_connect, albertvaka
Subscribers: albertvaka, apol, nicolasfella, broulik, kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D17081
Summary:
Bug: 399115
When using kdeconnect-cli --share the first argument was not recognised as a file when a relative path was specified.
Test Plan:
kdeconnect-cli --share File1.txt File2.txt : Check that both files are sent
kdeconnect-cli --sahre phabricator.kde.org : Check that web page is opend
Reviewers: #kde_connect, apol
Reviewed By: #kde_connect, apol
Subscribers: apol, kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D15787
Summary: You should be ableto unpair unreachable devices with the CLI
Reviewers: kdeconnect, albertvaka
Reviewed By: albertvaka
Subscribers: albertvaka
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D15677
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:
Adds "--name-only" and "--id-name-only", in addition to the already existing "--id-only".
This is useful for the zsh autocompletion which I've written.
Test Plan: The output is identical without the new flags.
Reviewers: #kde_connect, nicolasfella
Reviewed By: #kde_connect, nicolasfella
Differential Revision: https://phabricator.kde.org/D10875
Summary:
Previously, the .devices() call passed the parameters in the wrong order. I checked the order in the interface and the daemon, and this was the only place it went wrong.
Now running `kdeconnect-cli -l` correctly lists all paired devices, even if unreachable.
Test Plan: Tested with both a reachable and unreachable device.
Reviewers: #kde_connect, apol
Reviewed By: #kde_connect, apol
Subscribers: apol
Differential Revision: https://phabricator.kde.org/D9060
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
Summary:
The use of Q_FOREACH is advised against (https://doc.qt.io/qt-5/qtglobal.html#Q_FOREACH) since Qt 5.7 and will eventually be removed from Qt.
I replaced all occurrences with the range-for loop introduced in C++11 (except for the one in daemon.cpp in deviceIdByName which might have a bug / typo in it).
I added const to the container or casted it with qAsConst when appropriate to avoid unnecessary copies.
(This is my first submission. I did all the unit tests, and they all passed but I don't know how to show it here.)
Reviewers: #kde_connect, nicolasfella, apol
Reviewed By: #kde_connect, nicolasfella, apol
Subscribers: albertvaka, apol, nicolasfella
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D6724
Summary: Makes it possible to handle tel urls with any KDE Connect device
Test Plan: Manual testing
Reviewers: #kde_connect, albertvaka, nicolasfella
Reviewed By: #kde_connect, nicolasfella
Subscribers: nicolasfella
Differential Revision: https://phabricator.kde.org/D6120
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
