Overriding and defaulting them in the header doesn't make sense
For the dbus interfaces, we don't have any reasources to clean up or memory to be released. Meaning we can drop those lines too
* Moves the XML definitions of DBus interfaces and code generation from the different plugins
to kdeconnectinterfaces. Before each plugin had their own, some of them duplicated.
* Appends `// clazy:skip` to the generated interface files, so Clazy doesn't emit warnings
about them because they are missing the NOTIFY/CONSTANT keywords on Q_PROPERTIES.
* Makes kdeconnectinterfaces static on Qt5 as well (removes a difference with Qt6).
* Moves the generated files to a `generated` directory and updates the includes so they are
easily distinguished from other header files.
We've had separate title & artist for a while, and all clients should be
using those by now.
Also fixes the position change not being emitted when the song changes,
and fixes the values being written after emitting that they changed.
Continues the work started in !396 by rebasing it onto latest master and
making the "send clipboard" button from the plasmoid invisible when
automatic syncing is enabled.
I didn't find a way to do the same in kdeconnect-indicator and
kdeconnect-app (why do we have 3 UIs???), so in those we always show the
option for now.
Instead of having the DBus stuff in a separate class expose the plugin class itself like we do for the other plugins.
Replace the method-based API with properties.
Change the path to <device>/battery for consistency with other plugins
Summary: This will allow it to be used in the plasmoid and QML app via dbus.
Reviewers: nicolasfella
Reviewed By: nicolasfella
Subscribers: kdeconnect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D16551
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:
For real usecases of SMS support, we will almost always need access to the message history in some way
Specifically resolve T8338
Incidentally resolve T6651 since Telephony shall no longer create a notification
Test Plan:
Setup:
- Build corresponding Android-side diff (D11698)
- Build this diff
Step 1: Does anything at all work?
- Put a breakpoint in the handleBatchMessages method of the telephony plugin, ideally after constructing a Message object
- Use DBus to poke /modules/kdeconnect/devices/<deviceID>/telephony.requestAllConversations()
- Verify that the constructed Message is one you sent or received and that it is the most recent in the corresponding conversation
Step 2: DBus
- Open the Interface org.kde.kdeconnect.device.conversations of /modules/kdeconnect/devices/<deviceId>
- Poke activeConversations and verify an empty array is returned
- Poke requestAllConversationThreads
- Poke activeConversations and verify that a list of numbers has been returned. These are conversationIds
- Use a conversationId to call getFirstFromConversation
- Verify that the returned Message object is one which you recognize
- Note that if the message is an MMS it will be blank and meaningless. Try a different conversationId. MMS support "coming soon!"
Step 3: SMS App
- Use ccmake (or similar) to set SMSAPP_ENABLE to ON
- Build the project
- Run ./bin/kdeconnect-sms
- Verify that the app shows a list of everyone you have an SMS conversation with (MMS messages are stripped out)
- If you have the Contacts plugin working, verify that most contacts have their name and photo instead of their phone number
Reviewers: #kde_connect, nicolasfella, apol
Reviewed By: #kde_connect, nicolasfella, apol
Subscribers: andyholmes, apol, nicolasfella, #kde_connect
Tags: #kde_connect
Maniphest Tasks: T8338, T6651
Differential Revision: https://phabricator.kde.org/D11854
Summary: Current code only supports one player
Test Plan: Run two media sessions. Dbus inspection works fine, UI has some issues with values not updated, but out of scope for this diff
Reviewers: #kde_connect, apol
Reviewed By: #kde_connect, apol
Subscribers: apol, #kde_connect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D12546
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
Listen to dbus registrations. Remove all devices if the service dies,
create all devices back when restored.
Same for the NotificationsModel.
REVIEW: 124183
