Manually controlling QML Window from non-Qt C++ simulator
I'm entirely new to UI programming with Qt, so this might be a stupid question, but I did a bit of research and couldn't find much on this specific use case. Or maybe I did, but didn't recognize it as such ...
Anyway, I'm building a simulator without any use of Qt. We have our own event-scheduler controlling the various active objects of the simulation.
I would like to have a simple graphical visualization of what is going on in the simulation, and as I have QML available, I was thinking I might use that. However, this would require me to have manual control of the QML application window, at least that would be ideal.
I'm imagining creating some QApplicationWindow and giving a pointer to that to my simulator, and then manually calling refresh on that pointer when appropriate, but I can't find any good resources to read up on. Or again, maybe I just don't know what this is called!
Am I thinking right about this? And should this be possible this way?
Does your simulator communicate anything "to the outside world" ?
It does, it communicates with other software through TCP and UDP.
I was thinking this might be a way to do is as well. Launching the QML "visualizer" as a standalone tool in its own thread that simply just updates on receiving data on some port. I'm assuming something like this would be possible?
I think I would prefer it if the visualization was integrated in the simulator as a whole, though I don't have any strong reason for doing so, it just seems neater I guess.
Also, I guess it should be simple to launch a standalone visualizer directly from the simulator? I haven't started a separate process from C++ code before, but this I'm assuming wouldn't be that hard?
Thanks for the reply, I'm all ears and eager to learn, so all input is appreciated!
If the thing can run without any GUI but communicate what you want the let it run independently. Building your application on top of the data that the simulator send will allow you to have one or more application showing stuff from your single simulator instance.
That will also allow you to create distant remote application while the simulator runs maybe on a headless system.
@SGaist Thanks, this is slowly starting to make sense in my mind as well. It does make sense to encapsulate the simulator and visualizer in two separate applications. Thanks again!