Test App: Custom IoT Dashboard

[ahayzen-kdab]

Similar to #371 i'm using CXX-Qt to build a test app and will note things that i find wrong/tricky in here.

The app is a QML dashboard for communicating using WebSockets to other services that are on the same device or other devices on the network.

Category	Value
Build	Cargo only build
Qt	Qt 5.15 for now
Arch	arm64
OS	Linux (not yocto)

[ahayzen-kdab]

#469

Files specified in the qrc files don't cause cargo only builds to recompile, meaning that i need to manually touch the qrc or another tracked file each time i want to build when i have only changed files inside the qrc file.

[ahayzen-kdab]

#470

QDateTime::current_date should be QDateTime::current_date_time

[ahayzen-kdab]

Custom setters (#42) or a way of listening to signals from Rust would be useful.

As I have an object similar to a timer which the API would like to be

MyObject {
  running: true
}

But instead this needs to be

MyObject {
  Component.onCompleted: start()
}

[Be-ing]

a way of listening to signals from Rust

Surprisingly we didn't have an issue for this yet: #473

[ahayzen-kdab]

#474

When trying to create a QQuickPaintedItem in Rust and use a QPainter to draw on it with data from Rust crates, the only part missing was that we need a different parent type on the generated C++ class.

[ahayzen-kdab]

We should consider if a Rust file specified from the build script that has no bridge should be an error in the build script, or just a warning that can be ignored ?

[LeonMatthesKDAB]

I think warning would be good, then you could technically write a crawler and run the builder for each file, instead of having to list them all.
Not necessarily good practice, but would be possible.

[ahayzen-kdab]

CxxQtThread doesn't implement Copy or Sync which then means you have to be careful using async code with it.

Eg

let qt_thread = self.qt_thread();

tokio::spawn(async move {
   ...
   let read_future = read.for_each(|message| async move {  // or async it complains about no Sync
      qt_thread.queue(...);  // with async move this complains about no Copy
   }
});

This fails because CxxQtThread doesn't implement Copy as each inner loop of the for each needs it's own qt_thread or if it wasn't async move then CxxQtThread needs to be Sync as each gets a reference.

Instead this needs to be changed to the following structure

let qt_thread = self.qt_thread();

tokio::spawn(async move {
   ...
   let read_future = async move {
      while let Some(message) = read.next().await {
          qt_thread.queue(...);
      }
   }
});

Which is fine and works with our current code. Just something to consider if we could / would want to add Copy / implement Sync to CxxQtThread or not. Maybe we don't and this is OK as trying to prove that that is safe might be tricky ?

[ahayzen-kdab]

The problem turns out to be the UniquePtr which the QtThread is inside. The workaround is fine for now.

[LeonMatthesKDAB]

Ah, damn...

[LeonMatthesKDAB]

UniquePtr actually implements Send&Sync, if the underlying type does.
So should be fine if CxxQtThread itself is Send&Sync.

[ahayzen-kdab]

Interesting, i'll try this out see if it does work, we also need to check if there is enough locking and safety in the C++ side for it to be Sync ....

[ahayzen-kdab]

Split into #481