Unfortunately, most issues are in Kirigami and we can't fix them from our side. Namely, these things remain unfixed:
- `Kirigami.PlaceholderMessage` are not read by screen readers
- When navigating with the keyboard, pressing tab selects elements from right to left, which is weird
- When navigating with the keyboard, the selected element is not highlighted
- `Kirigami.Action` that don't have a `text` property don't use the `Accessible.name` property when using a screen reader.
## Summary
Back before the KF6 release, I set the craft.ini file to explicitly require master versions of some dependencies which did not have appropriate versions available. (!631)
Now that those are released, we should remove those overrides (also because they break the build!)
## Test Plan
Tested the pipeline on a private branch: https://invent.kde.org/network/kdeconnect-kde/-/pipelines/621529
Given this is passing, I plan to check in this change without waiting for another pipeline run.
This allows us to avoid asking the user for permission for remote control on Wayland every time kdeconnectd is restarted for whatever reason (for example logging out or rebooting), at least in theory. The idea is that the SelectDevices call now also accepts a restore token, and if the user grants permission to persist a restore token will be returned in the response of the Start call.
Currently https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/265 is required for this to work at all with Plasma 6, and even then persistence only works in the same session (for example if I restart kdeconnectd then I only get the notification instead of the permissions prompt), if I reboot the system then the token gets invalidated and the permissions dialog appears again, not sure if the issue is with what I'm doing here or if that's a bug in the portal.
Things that need to be checked:
- What happens if the portal implementation only has v1 of the protocol and not v2 (the one with persistence)?
- In particular what happens for the SelectDevices call if a restore token is given despite the portal not supporting it
- Seems fine with xdg-desktop-portal 1.14.4 at least
- For the Start call we'll need to handle the case of the user denying the persistence request anyway
- Where and how should the restore token be stored?
- ~~I used KConfig just so I have something to test, but the restore token isn't really a setting~~
- Updated to use `KSharedConfig::openStateConfig`
- Most of KDE Connect's settings and data appear to be for each connected device
- The device name is a global setting, but it's implemented using QSettings rather than KConfig, and currently only setName and getName is exposed in `core/kdeconnectconfig.h`
BUG: 479013
