How is this feature advancing? Because I see there was a diff and a commit concerning it, but the code isn't on master I don't think.

I haven't been working on this lately because even though quite a few features work (permissions, creating new files, renaming, moving, deleting...), I was stuck on several major problems, in particular transferred files are empty until the device is rebooted (an outputstream doesn't close properly or something like that I think).

Here's the StackOverflow question: https://stackoverflow.com/questions/46060113/writing-with-an-outputstream-to-a-documentfile-data-seem-to-be-written-but-file, feel free to take a look and give a vote

So, is the revision good?

That's what I had in mind too. Right now there's an intermediate screen with the FindMyPhone UI because I copy-pasted so it looks stupid but I couldn't be bothered :D

That's what I did, yes. I don't think there is any other way, Android really doesn't want anyone to access the filesystem without their API :/

I lied, I've actually been working on this. I'm far from done yet, but at least I managed to write to the SD card, which wasn't possible before. I'm currently trying to make it work through the SFTP plugin. I'll upload a diff when I have a somewhat working version to get some feedback.

Reverted the erroneous renaming of d-pointers. And properly renamed a few missing member variables

In D7312#136722, @albertvaka wrote:

In D7312#136390, @jeanv wrote:

What do you think about naming them d_ptr like in the Qt doc? It would be more explicit to newcomers that this is deliberate.

In most KDE projects they are just called 'd', and I think that adding '_ptr' won't make it that more clear, but do as as you wish :)

In D7312#136345, @albertvaka wrote:

I see some inconsistencies, for example in DaemonPrivate you changed
QSet<LinkProvider*> mLinkProviders; to

`QSet<LinkProvider*> m_linkProviders;`

while in KdeConnectPluginPrivate you changed

`Device* mDevice;` to
`Device* device; `

Also, I see you renamed d-pointers (https://wiki.qt.io/D-Pointer) like QScopedPointer<KdeConnectPluginPrivate> d; to QScopedPointer<KdeConnectPluginPrivate> m_pluginInfos; and we should keep the naming so it is clear we are using this programming pattern.

Include double pointers (Type **foo -> Type** foo)

In D7192#135236, @nicolasfella wrote:

I guess this can be closed now?

Absolutely

Is someone already on this task? Because I'm interested in doing it.

Looks good to me

In D7192#134274, @apol wrote:

In D7192#134257, @jeanv wrote:

In D7192#134232, @apol wrote:

Please see https://phabricator.kde.org/D7224

I see what you mean. Your solution does seem better.

Then please, review my patch :)

In D7192#134232, @apol wrote:

Please see https://phabricator.kde.org/D7224

These two stackoverflow discussions, here and here, seem to answer how to write to external storage with the Storage Access Framework. Android also provides docs for the SAF, but it's not great imo.

I noticed I don't have write access on my SD card with the SFTP plugin, is it part of this task?

Use isEmpty() instead of QString::null.
Create uniqueName after we have checked if identity is empty.

Here's what I found:
Concerning the naming of the service, having a unique name per instance is actually part of D-Bus's specifications. It's supposed to be implemented in VLC (see the source here, line 201) but there was a bug that only got fixed june 18 and since I'm on KDE Neon, I have an older version installed. Indeed if I check the D-Bus connections in Manjaro with two instances of VLC, I get two connections.

I'll see what I can do, although I'd rather not claim the task since I don't know anything about DBus (yet, it's a good excuse to learn) and might get stuck.

I like it! Although I think we should keep the feature of knowing if the phone is charging or not. Just something like:

The volume plasmoid works correctly: both players are visible.

I tried to take a look at this, even though I didn't know anything about DBus.

Revision D6730 has been accepted and removes the need for this one.

In D6730#127238, @albertvaka wrote:

Looks good to me. I will merge this in as soon as I have a moment. Can you check my comment about IPv6? I think v6 should just work.

• mHostAddress is now in LanDeviceLink instead of DeviceLink
• Device::deviceLink changed to Device::getLocalIpAddress and only returns a QHostAddress instead of the whole link
• the block in LanDeviceLink::reset that gets and stores the IP address is cleaner now

In D6724#127025, @albertvaka wrote:

Can you give me your email, so I can push this on your behalf?

This seems to work for me. The correct IP address is stored and reused.

I realized this is just bad.

Instead of transmitting all IP addresses for the device, maybe store the correct one in LanDeviceLink

In D6730#126708, @apol wrote:

In general, this looks like an overkill to me.
Maybe it would make sense to allow the DeviceLink to tell which IP it's connected to?

In D6730#126297, @nicolasfella wrote:

Just upload two separate diffs, one for each repo

Loop on the addresses received in the network package and determine which one is open to KDE Connect

Transmit all ip addresses to the desktop application so that it can determine which one to use

Okay, I did it differently (close to what you said):
The android application sends all IPs it can find in the device interfaces, then the desktop application loops on those IPs and tries to open a TCP connection on the current IP on the requested port: if it succeeds before the timeout, that's the IP that will be used to mount with sshfs.

In D6730#125922, @sredman wrote:

I wonder if there is a different way to fix this bug? I actually (successfully, including sshfs) use OpenVPN to get around poorly-managed networks where KDE Connect would otherwise not work very well, so making this change would break that for me :)

Maybe rather than blacklisting tun connections, it would make sense to make the sshfs command more robust? I haven't looked into this, so I don't know what that might involve.

Remove the remaining Q_FOREACH in daemon.cpp in deviceIdByName and rename the variable d to device to avoid confusion.

In D6724#125760, @nicolasfella wrote:

except for the one in daemon.cpp in deviceIdByName which might have a bug / typo in it

This seems to be just really bad naming. d is also the name of a member variable. The Device* should be renamed to avoid such confusion