Summary:
The code for visually disabling the input field is not needed any more since the field is completely hidden when not needed. Also drop the custom available property from the text field.
More cleanups will follow. My long-term goal is to reuse the code in the app to enable remote keyboard input on non-Plasma DEs
Test Plan: (De)activate the remote keyboard on Android.
Reviewers: #kde_connect, apol
Reviewed By: #kde_connect, apol
Subscribers: apol, #kde_connect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D12669
Summary: It also makes it clearer that the top line is not a notification, but a header.
Reviewers: #kde_connect, apol
Reviewed By: #kde_connect, apol
Subscribers: #kde_connect
Differential Revision: https://phabricator.kde.org/D11646
Summary: This adds a refresh button to the plasmoid if no device is connected.
Test Plan: Refreshing works, and the button only appears when no devices are connected.
Reviewers: #kde_connect, nicolasfella
Reviewed By: #kde_connect, nicolasfella
Subscribers: apol, nicolasfella, #kde_connect
Differential Revision: https://phabricator.kde.org/D11501
Summary: Like we do for the notifications in the plugin already. Passing the title and text separately to the plasmoid could be useful later as well.
Reviewers: #kde_connect, albertvaka
Reviewed By: #kde_connect, albertvaka
Subscribers: #kde_connect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D7457
Summary:
Make the plasmoid content transparent
Include battery info in header
Only show remotekeyboard input if available
Make header always centered
before:
{F3820966}
after:
{F3820965}
Reviewers: #kde_connect, apol
Reviewed By: #kde_connect, apol
Subscribers: jeanv, albertvaka, apol, #kde_connect
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D6943
Summary:
Notifications, QML Text and QLabel accept a HTML subset,
which does not make sense for device names.
BUG: 382243
Test Plan:
Sent a pair request and accepted it, device name
now shown as plain text everywhere.
Reviewers: #kde_connect, albertvaka
Reviewed By: #kde_connect, albertvaka
Subscribers: #kde_connect
Differential Revision: https://phabricator.kde.org/D6640
Summary:
Show an icon for each notification which has an icon.
Show a toolbutton which can be used to reply to notifications which offer a quick reply.
Reviewers: #kde_connect, albertvaka
Reviewed By: #kde_connect, albertvaka
Subscribers: albertvaka
Maniphest Tasks: T4674, T4658
Differential Revision: https://phabricator.kde.org/D6058
Also ensure that it wraps instead of overflowing in case the text gets too long on translated system.
Differential Revision: https://phabricator.kde.org/D4478
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
No need to show the FullRepresentation to figure out the status of the
plasmoid.
Moves the code back to the main.qml file so that we're always tracking if
there's actually paired devices.
REVIEW: 122912
Provide a good initial size
Use compact representation when on a panel, full when on the desktop (this
prevented the icon to show on the system tray).
Reviewed by Albert Vaca
i18n accepts extra arguments to properly perform the
replacements of %1 by the proper value, we have to use that
instead of calling .arg in the resulting QString so i18n can
do some magic for us.
