kdeconnect: choose the first avilable device

[omkar-mohanty]

Fixes #1612

[omkar-mohanty]

@MaxVerevkin is this the correct direction to go for? I am a bit unsure if all the cases are handles.

[MaxVerevkin]

@MaxVerevkin is this the correct direction to go for? I am a bit unsure if all the cases are handles.

I think a better way to organize things is to do something similar to bluetooth.rs and battery/upower.rs.

[omkar-mohanty]

@MaxVerevkin I organized kdeconnect.rs like bluetooth.rs, I think it should be ready now.

[MaxVerevkin]

When device is not found, the block should wait until a new device is added, then it can try searching again. Right now there is a tight loop which maxes the CPU usage...

---

And to be honest, I don't quite understand why I decided to use a tokio task + channels to watch for updates when I was porting this block. It doesn't make sense. Instead a Device can contain three streams which are .next().awaited in wait_for_change.

[omkar-mohanty]

@MaxVerevkin for some reason cargo fmt does not seem to work in my local machine

[MaxVerevkin]

@MaxVerevkin for some reason cargo fmt does not seem to work in my local machine

cargo fmt unfortunately does not format files which are included via macros (in our case the define_blocks! macro in blocks.rs), so if you don't use rust_analyzer, you have to run rustfmt --edition 2021 <file>.

[omkar-mohanty]

@MaxVerevkin is the PR close to what you have in mind?

[MaxVerevkin]

@omkar-mohanty CPU usage is still 100%

[MaxVerevkin]

Now CPU usage is 100% even if the device is available