<div dir="ltr">It finally found some time to test it and it works perfect! I think we could merge it already :) We should add a confirmation before removing a host and that would be enough for a first release.<br><br>Is there any other think you think that needs to be improved?<br><br>I would maybe add some text saying that you should only use this option if your device is not automatically detected, to avoid confusion from new users.<br><br>On Wed, Oct 22, 2014 at 4:59 PM, Achilleas Koutsou<br><<a href="mailto:achilleas.k@gmail.com">achilleas.k@gmail.com</a>> wrote:<br>> On 22/10/14 21:41, Albert Vaca wrote:<br>>><br>>> Awesome, it's very nice to see that good progress! No worries with the<br>>> long mail, and sorry in advance to be lazy to read through it and answer<br>>> it until today ;)<br>><br>><br>>> On Oct 19, 2014 9:48 AM, "Achilleas Koutsou" <<a href="mailto:achilleas.k@gmail.com">achilleas.k@gmail.com</a><br>>> <mailto:<a href="mailto:achilleas.k@gmail.com">achilleas.k@gmail.com</a>>> wrote:<br>>>  ><br>>>  > If anyone wants to check it out, it's all on the 'manualip' branch on<br>>> my<br>>>  > github fork:<br>>> <a href="https://github.com/achilleas-k/kdeconnect-android/tree/manualip">https://github.com/achilleas-k/kdeconnect-android/tree/manualip</a><br>>>  ><br>>><br>>> You managed to only change the Android side? Nice! But... isn't the<br>>> desktop side expecting identify packets to be received via UDP broadcast<br>>> only? Because you are sending TCP packets I guess (?)<br>><br>><br>> Well, the new provider is almost a complete copy of the LanLinkProvider, so<br>> it works the same way. The difference is that, where LanLinkProvider sends a<br>> DatagramPacket addressed to -1.-1.-1.-1 (LanLinkProvider:249),<br>> CustomLinkProvider creates several DatagramPackets, each one addressed to an<br>> IP from the user-supplied list.<br>><br>>>  ><br>>>  > In terms of the interface, there is a new menu item below "KDE Connect<br>>>  > Settings" labelled "Custom Device List". This is a simple item list<br>>> where one can add a new host or IP by typing and hitting the "Add" button.<br>>>  > Removing items is done by simply touching the existing item in the<br>>>  > list. There is no confirmation dialogue for removing items (this will<br>>> be<br>>>  > added soon).<br>>>  ><br>>><br>>> Couldn't we use the same main device list? I think it will be cleaner,<br>>> but anyway it's just about the interface and we can change that later<br>>> once the functionality is there.<br>><br>><br>> We could have an "add device" button on the main screen, I guess. The reason<br>> I added it as a separate option was because the first time we talked, you<br>> mentioned that this might be considered an advanced feature and for normal<br>> use, the app should "just work", a decision which I totally understand and<br>> support. Final decision is on you though and it's a minor change we can do<br>> later.<br>><br>>>  > There is no validation done to the entered text. Initially, I was<br>>>  > planning on validating the input string to make sure it's a valid IP<br>>>  > address. I restricted entry to numbers and periods only and<br>>>  > had the interface use the numerical keyboard. I later realised that<br>>>  > hostnames should also be valid items, so one can now enter a host or<br>>>  > domain name that gets resolved to an IP address.<br>>>  ><br>>><br>>> Makes sense.<br>><br>><br>> Good to know.<br>><br>><br>>>  > The custom device list is saved as a single string, stored in the<br>>>  > DefaultSharedPreferences. The string is constructed by concatenating<br>>> all<br>>>  > entries, separated by a single comma ",". I would use a String set, but<br>>>  > that requires API Level 11 and KDE Connect has a min level 9. I'm open<br>>>  > to suggestions if someone has a better idea on how to store the list.<br>>>  ><br>>><br>>> I faced the same issue somewhere else and I solved it the same way.<br>>><br>>>  > Issues/limitations:<br>>>  > - I have only managed to test pairing (and using) two devices, each on<br>>> a<br>>>  >   different physical network, but both connected to the same VPN. The<br>>>  >   VPN was my private OpenVPN in TUN mode. I haven't tested TAP mode, or<br>>>  >   any other kind of VPN. There is no *theoretical* reason why it<br>>>  >   shouldn't work, but I can't be certain without testing.<br>>>  > - The pairing doesn't work via the internet, by forwarding ports on my<br>>>  >   router. My phone was on the mobile network (3G), I forwarded the<br>>>  >   appropriate ports on my router, I added my home's public IP to the<br>>>  >   list, but the kdeconnect daemon couldn't detect the phone. I ran<br>>>  >   tcpdump and saw that my desktop does in fact receive the tcp and udp<br>>>  >   packets, but the kdeconnect daemon (running using --nofork), only<br>>>  >   occasionally displays "LanLinkProvider::connectError: Fallback (1),<br>>>  >   try reverse connection". I'll investigate whether any changes are<br>>>  >   required on the desktop application side. I suspect it might be an<br>>>  >   issue with my provider blocking the packets from the desktop to the<br>>>  >   mobile. To test this properly, I need two networks where I can<br>>> forward<br>>>  >   ports on both ends.<br>>>  ><br>>><br>>> I will do some testing when I have a chance (I'm boarding a plane right<br>>> now), but about establishing connections through the Internet, I think<br>>> it's not a problem if it doesn't work: it would be too laggy anyway for<br>>> touchpad and other features, and you probably don't want to transfer<br>>> files over 3G either.<br>>><br>>> :D<br>><br>><br>> Great. Can't wait to hear how it works for you.<br>><br>> --<br>> Achilleas<br>><br></div>