Passing Rust native structs into slint like in Qt

[bryce-happel-walton]

In Qt you can define properties of Classes like such:

class Data : public QObject {

   Q_Property(double DataParameter read getDataParameter write setDataParameter notify DataParameterChanged)
   
   private:
      double DataParameter;
      
   public:
      double getDataParameter();
      void setDataParameter(double);
      
   signals:
      DataParameterChanged(double);
}

This allows you to register the class as a global in qml and access it without defining anything about the class in your qml file.

import Data // this is the C++ class

Text {
    text: Data.DataParameter // directly accessing the property through the read definition
}

Qt does its magic to allow this binding to be seamless for developers.
With Slint I've had to define every parameter for my struct in Rust and in Slint then bind them

In Slint:

export global SData {
    in property <int> Parameter;
}

In Rust:

struct Data {
    Parameter: u16
}

window.global::<SData>().set_Parameter(Data.Parameter.into());

Maybe I'm doing it wrong, but this feels very clunky compared to Qt.
It would be nice to define an async update function to be called when the rust data is changed that passes the data slint. I've implemented this myself, but it is not in a way that I like and it feels like maybe I'm using Slint wrong.

Is there a reason we don't have something similar to Qt for this, or has it just not been implemented yet?

[ogoffart]

In Slint, the .slint files needs to be self contained and the Slint compiler need to know about every type at compile time. (In QML, it is much more dynamic and we can register type t runtime)
So you can do the opposite by declaring a export struct Data { ... } in slint and using that in rust.

We do have plan to be able to import rust structs. This is tracked in #1726

[bryce-happel-walton]

In order to separate my logic from the ui I have made build.rs generate copies of my rust structs in slint and I made a bridge function to translate between them. I'm not sure of the performance implications, but it just feels wrong anyways. Do you have a suggestions for an alternative while still separating the logic?