The RemotecommandsPlugin lacks a graphical frontend.
Inlcudes a Dbus Interface for fetching the commands and a Model exposing them to QML. For this I oriented on the NotificatonsPlugin.
apol |
KDE Connect |
The RemotecommandsPlugin lacks a graphical frontend.
Inlcudes a Dbus Interface for fetching the commands and a Model exposing them to QML. For this I oriented on the NotificatonsPlugin.
Open command list in app, check available commands, trigger some. Do same for CLI.
Activate edit action, check KCM opening on remote device, add command, check for new command in list
Automatic diff as part of commit; lint not applicable. |
Automatic diff as part of commit; unit tests not applicable. |
interfaces/remotecommandsmodel.cpp | ||
---|---|---|
123 | Should it maybe be beginResetModel? Looks like we're setting it up from scratch. Then we'd need to m_commandList.clear() | |
168 | const | |
169 | No need to check bounds if we call m_commendList.value(row); | |
interfaces/remotecommandsmodel.h | ||
32 | Should be RemoteCommandsModel. | |
71 | QVector | |
plugins/remotecommands/remotecommand.h | ||
21 ↗ | (On Diff #36077) | Don't do that just here once |
30 ↗ | (On Diff #36077) | Wouldn't it make sense to just return a QVariantMap or QJsonObject? Creating a dbus interface just to make it constant doesn't make a lot of sense. |
plugins/remotecommands/remotecommandsdbusinterface.h | ||
48 ↗ | (On Diff #36077) | Why does a dbus interface have a receivePacket? |
plugins/remotecommands/remotecommand.h | ||
---|---|---|
30 ↗ | (On Diff #36077) | I thought about that too when it was already too late. This way we already expose the parsed data, otherwise we would need to do that in the model (which would be fine). But the current approach would be beneficial if something else would use the DBus interface (some hypothetical extra UI) so we don't need to implement the parsing twice. |
plugins/remotecommands/remotecommand.h | ||
---|---|---|
30 ↗ | (On Diff #36077) | Any UI will end up using the RemoteCommandsModel. |