I would strongly suggest adding an "soft unpair" feature, one that merely disconnects but saves all the permissions: 1. This would allow users to quickly unbork the app, which is important given the high failure rate of pairing. (see Bug #410316 for an illustration of just how insidious this problem is, even in the context of just one network) Unpairing usually fixes the problem - ofc the problem shouldn't exist but having some solution is better than nothing. 2. Furthermore, the current "unpair" button is just dangerous, since users are given no warning that if they tap it all their app permissions and settings will be lost. Many users will attempt to tap it in the hopes of re-establishing the connection - I know I did and was surprised when I had to re-enable all the permissions and settings (at least 20 taps, quite tedious) So there should be a quick toggle to disconnect and re-connect and an additional option to "unpair permanently" (the same thing as current unpair). The first option should keep all the settings in place so that the connection can be quickly resumed. The second option should warn users that they are going to lose all their settings by proceeding.
I don't want to change the title but propose you don't call it "soft unpair". I think disconnect is sufficient. I agree that this feature is needed but for other reasons. What about the use of kdeconnect in a small office or household?: 1. members want to quickly share among them a file without setting up a network share. 2. members don't want to be permanently connected to avoid clipboard paste conflicts 3. privacy issues in Android Concept of clipboard paste conflict can be described as follows. User A and B are paired and share the clipboard. Both are editing a document and do a lot of corrections using copy/cut and paste. User A copies a text and without knowing user B does the same right after. Then user A pastes not his own copy but that of user B and is confused. The privacy issue in Android I discovered while using the virtual keyboard. Just above the virtual keyboard there is an area that shows a button of recently cut/copies text from the clipbaord that allows you to paste it by tapping it. It shows a fragment of the text and it was constantly changing while I was answering a chat message. I discovered they were not the usual suggestions while you enter your text but it was copied text of my wife while she was editing on her paired device In this aspect I think that kdeconnect counts too much on individual use and it does not on use in households or small office teams. There should at least be an easy disconnect option and auto-connect should be optional per device. That way you can minimally distinguish between your own devices and that of others and maintain some respect and privacy. Like @leftcrane explains, unpair is too drastic and something like (manual) connect and disconnect would be desirable.
(In reply to René from comment #1) > 2. members don't want to be permanently connected to avoid clipboard paste > conflicts > 3. privacy issues in Android Part of this is covered by Bug 392164 . It's not really a small office or household specific issue though. Android is no longer really open source, phones are more of magical blackboxes nowadays instead of portable personal computers they were a decade or so ago. The "soft unpair" (I'd rather say pause) approach would be okay as a quick workaround, but I believe that finer-grained control is what's more desired here. For example the Run commands plugin gets it right, the user needs to whitelist commands first. Some examples of what's way too coarse-grained: - Clipboard: The lack of "single shot" sends just makes it too much of a security risk. Generally I'd also expect the automatic synchronization to drain phone battery quite a bit. - MprisRemote + Multimedia control receiver: Would be great to start/stop/pause music and maybe some videos, and also adjust the volume, but that comes hand in hand with sending info on every piece of multimedia playing with no exceptions. There's no way to disable metadata sending even though the multimedia buttons on some keyboards already work quite well without knowing what's playing, and there's also no whitelist to limit to just some specific programs as metadata can be useful after all. - LockDevice: Just recently found out that this isn't just for locking, it's also for no questions asked unlocking, going both ways. The "Locks your systems" made it look like a security feature I figured I'd use one day as it sounds great to be able to lock a remote host, but there aren't any settings so I ended up with a huge security hole of connected devices being able to unlock each-other. Generally KDE Connect is way too trusting, and the default settings are really not secure. I really appreciate the handful of features I use, but I just keep most of the plugins disabled as it's too risky to have them enabled. Speaking of which, relevant heads up: With LockDevice I got to know the hard way that disabling plugins don't actually unload them, so highly likely it's not enough to just temporary disable Clipboard either to achieve what's desired here. Also, there's a potential clipboard-specific solution Wayland "promised", but unfortunately it's not here (yet?). If clipboard reading would need user interaction, then clipboard contents simply just couldn't spread unintentionally. While this would break interaction-free automatic clipboard synchronization, I'd enable such a secure clipboard option in KWin without a second thought, and the KDE Connect Clipboard plugin would also become more useful by not sending everything.