kdeconnect-kde/plasmoid/package/contents/ui/DeviceDelegate.qml

220 lines
6.8 KiB
QML
Raw Normal View History

/**
* Copyright 2013 Albert Vaca <albertvaka@gmail.com>
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of
* the License or (at your option) version 3 or any later version
* accepted by the membership of KDE e.V. (or its successor approved
* by the membership of KDE e.V.), which shall act as a proxy
* defined in Section 14 of version 3 of the license.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program. If not, see <http://www.gnu.org/licenses/>.
*/
2014-06-18 01:35:48 +01:00
import QtQuick 2.1
import QtQuick.Layouts 1.1
2014-06-18 01:35:48 +01:00
import org.kde.plasma.core 2.0 as PlasmaCore
import org.kde.plasma.components 2.0 as PlasmaComponents
import org.kde.kdeconnect 1.0
kdeconnect-kde: Add remotekeyboard plugin 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
2017-01-10 20:12:42 +00:00
import QtQuick.Controls.Styles 1.4
PlasmaComponents.ListItem
{
id: root
readonly property QtObject device: DeviceDbusInterfaceFactory.create(model.deviceId)
kdeconnect-kde: Add remotekeyboard plugin 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
2017-01-10 20:12:42 +00:00
RemoteKeyboard {
id: remoteKeyboard
device: root.device
onKeyPressReceived: {
if (specialKey == 12) // Return -> clear
remoteKeyboardInput.text = "";
else {
var sanitized = "";
for (var i = 0; i < key.length; i++) {
if (key.charCodeAt(i) > 31)
sanitized += key.charAt(i);
}
if (sanitized.length > 0 && !ctrl && !alt)
remoteKeyboardInput.text += sanitized;
}
}
}
Column {
width: parent.width
2014-01-27 16:52:29 +00:00
RowLayout
2014-01-27 16:52:29 +00:00
{
Item {
//spacer to make the label centre aligned in a row yet still elide and everything
implicitWidth: ring.width + browse.width + parent.spacing
}
2014-01-27 16:52:29 +00:00
PlasmaComponents.Label {
horizontalAlignment: Text.AlignHCenter
elide: Text.ElideRight
2014-01-27 16:52:29 +00:00
text: display
Layout.fillWidth: true
}
//Find my phone
PlasmaComponents.Button
{
FindMyPhone {
id: findmyphone
device: root.device
}
id: ring
iconSource: "irc-voice"
visible: findmyphone.available
tooltip: i18n("Ring my phone")
onClicked: {
findmyphone.ring()
}
2014-01-27 16:52:29 +00:00
}
2014-02-14 16:11:41 +00:00
//SFTP
2014-02-05 19:26:54 +00:00
PlasmaComponents.Button
{
Sftp {
id: sftp
device: root.device
2014-02-05 19:26:54 +00:00
}
2014-02-14 16:11:41 +00:00
id: browse
iconSource: "document-open-folder"
visible: sftp.available
tooltip: i18n("Browse this device")
2014-02-05 19:26:54 +00:00
onClicked: {
2014-02-16 06:55:15 +00:00
sftp.browse()
2014-02-05 19:26:54 +00:00
}
2014-01-27 16:52:29 +00:00
}
2014-02-14 16:11:41 +00:00
2014-01-27 16:52:29 +00:00
height: browse.height
width: parent.width
}
2014-02-14 16:11:41 +00:00
kdeconnect-kde: Add remotekeyboard plugin 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
2017-01-10 20:12:42 +00:00
//RemoteKeyboard
PlasmaComponents.ListItem {
sectionDelegate: true
visible: remoteKeyboard.available
width: parent.width
Row {
width: parent.width
spacing: 5
PlasmaComponents.Label {
id: remoteKeyboardLabel
//font.bold: true
text: i18n("Remote Keyboard")
}
PlasmaComponents.TextField {
id: remoteKeyboardInput
textColor: "black"
height: parent.height
width: parent.width - 5 - remoteKeyboardLabel.width
verticalAlignment: TextInput.AlignVCenter
style: TextFieldStyle {
textColor: "black"
background: Rectangle {
radius: 2
border.color: "gray"
border.width: 1
color: "white"
}
}
Keys.onPressed: {
if (remoteKeyboard.available)
remoteKeyboard.sendEvent(event);
event.accepted = true;
}
}
}
}
//Battery
PlasmaComponents.ListItem {
Battery {
id: battery
device: root.device
}
sectionDelegate: true
visible: battery.available
PlasmaComponents.Label {
//font.bold: true
text: i18n("Battery")
}
PlasmaComponents.Label {
text: battery.displayString
anchors.right: parent.right
}
}
//Notifications
PlasmaComponents.ListItem {
visible: notificationsModel.count>0
enabled: true
sectionDelegate: true
PlasmaComponents.Label {
//font.bold: true
text: i18n("Notifications")
}
PlasmaComponents.ToolButton {
enabled: true
visible: notificationsModel.isAnyDimissable;
anchors.right: parent.right
iconSource: "window-close"
onClicked: notificationsModel.dismissAll();
}
}
Repeater {
id: notificationsView
model: NotificationsModel {
id: notificationsModel
deviceId: root.device.id()
}
delegate: PlasmaComponents.ListItem {
id: listitem
enabled: true
onClicked: checked = !checked
PlasmaComponents.Label {
text: appName + ": " + display
anchors.right: dismissButton.left
anchors.left: parent.left
elide: listitem.checked ? Text.ElideNone : Text.ElideRight
maximumLineCount: listitem.checked ? 0 : 1
wrapMode: Text.WordWrap
}
PlasmaComponents.ToolButton {
id: dismissButton
visible: notificationsModel.isAnyDimissable;
enabled: dismissable
anchors.right: parent.right
iconSource: "window-close"
onClicked: dbusInterface.dismiss();
}
}
}
//NOTE: More information could be displayed here
}
}