In D11773#237060, @kossebau wrote:

In D11773#236515, @mtijink wrote:

Wouldn't it make more sense to integrate this into the existing "Find my phone" plugin?

Perhaps. Depends if people think there are devices which would just be searched *for* or devices which are just searched *from*. In that case one might prefer to have the plugins separated, as proposed initially here.

For one, any mobile device is candidate both for being searched for and searched from, given their mobile nature :)
On the other hand, not any connected device and its users should be able to trigger the Find feature for any other connected device (think device for visitors/kids which should not be able to locate host's/mum's phone, but the other way around you want to be able).

That's why I proposed this as separate plugin, to allow separate enabling in which direction the Find feature works.

Works nicely, thanks!

The code generally looks good to me! I added a few comments.

Wouldn't it make more sense to integrate this into the existing "Find my phone" plugin?

I can't apply the patch cleanly, and it seems as if you removed all previous changes, only adding the newest update.

Move code in both if/else branch outside if

Some icons not yet themed correctly:

• The exclamation icon when you select a paired, but unconnected device
• The volume icon in the MPRIS activity

Same here.

The diff doesn't appear correctly either, right? Maybe it's because the code already is in a branch?

The code looks good. I'll test once the Android side is done.

I don't know, it didn't have the problem on my desktop.

I like it!

I added a couple of code comments.

Fixed the bug happening on Oreo.

Looks good. Is depending on PulseAudioQt okay already?

The larger notification icon has some problems though, so disabling that one. The music icon (the album art placeholder) was the larger problem anyway.

Updated according to @albertvaka's suggestion.

• Already done
• Not according to Android guidelines
• See D11627

Android part done/workable, desktop not yet.

Sorry, we had a misunderstanding. I thought you didn't especially like it, but was okay with this being merged (for now).

In D11017#229576, @nicolasfella wrote:

Out of scope for this patch, but would it make sense to add KIO support for this? Media files could be on e.g. a samba share, but even then the thumbnails could be elsewhere (like /tmp)

In D11501#229604, @apol wrote:

Meh, it's a workaround to a bug. We should investigate the bug, not add UI to fix what we can't fix with code. :P

Screenshot:

Rebased on master

Rebasing on master

Patch looks good. Another option is (2), as used for files.

I fixed the problem: the code now only counts the the art as transferring once the remote actually replies with the art.

In D11017#226787, @albertvaka wrote:

The payloads API seems to be broken and is causing problems in the notifications plugin because we send the notification icons with it (see my email in the kdeconnect mailing list). I think we should make sure it works well before making more plugins use it.

Looks good to me!

If you think differently about this, please say so, otherwise we'll forget and it won't change anymore. Especially since the code's already in master (and already released by now).

Didn't test it yet, but it generally looks like a good patch!

In D3373#227362, @avamander wrote:

Maybe you could please tell me what was it renamed to?

Are you sure this is needed? It appears to transfer CanPause etc. just fine when I start an MPRIS player, without the patch. Do I need the git-master gwenview to reproduce the issue?

In D11018#219325, @nicolasfella wrote:

I thought about that, but that seems fragile to me. The best I could come up with is a timer to remove the urls from the list.

Have you actually tried any of those?