@SimonSchroeder said in Creating C language bindings for Qt - Where do I start?:

using just a plain void* instead of introducing a C struct

@Platinum-Lucario should read and be aware of the discussion we had recently in QGraphicsTextItem * and void * conversion error and the conclusion at https://forum.qt.io/post/815140. The gist is that where Qt uses C++ multiple inheritance you lose information and go wrong if you are not careful about what you pass as a C void *.

@JonB said in How do I create real C# bindings for Qt6?:

If you want to do it for Qt6, and if QtSharp has suitable free use licensing, would that not be a good place to start rather than from scratch?

I'll definitely give it a go! From what I can see, it's under the Apache License 2.0, so it's possible.

@fromis_9 Controls usually provide a signal to indicate that a change has come from a user interaction signal, you should use this one instead of the "raw" <property>Changed signal that will fire both on backend and frontend changes.

For CheckBox it is the toggled signal, for ComboBox activated, for TextField textEdited, ...

So in your case it would be:

CheckBox { id: qmlCheckBox checked: backend.myCheck onToggled: backend.myCheck = checked }

Make sure to also not emit the notify signal in the setter if the property doesn't actually changed, generally done with an if at the start:

void Backend::SetMyCheck(bool myCheck) { if (myCheck == m_myCheck) return; m_myCheck = myCheck; emit myCheckChanged(); }

@trusktr said in Auto re-run property bound code in C++ outside of a class?:

@sierdzio Have a look at Solid.js. People are loving the dependency-tracking reactive patterns.

What does that have to do with me? ;-)

What is the Qt equivalent of moving state outside of a QML component and both:

logging it when it changes rendering it inside two different compoments

?

Typically this involves creating a C++ object which holds the state, has properties and signals etc. This solves both of your points nicely and keeps UI and logic nicely separated.

@trusktr With property bindings in C++ the answer is easy: the inspiration were property bindings from QML :-) They came first (around 2007, back in Qt 4.7 days).

And with QML I think the inspiration was just in the nature of this (by then) new language: QML is a declarative language so you need a mechanism to automatically update values when their components change.

And since Qt had signals and slots since early days (early '90), it was quite straightforward to implement this using existing "backend" technology.

@jhayar Could you please describe your solution to the "Can't toast on a thread that has not called Looper.prepare()"?