> I don't think Qt, or QML for that matter, is flexible enough to fit into an existing, complex architecture with its own concepts and data structures. What I need is something that I can feed my own inputs through a simple plain data API, and get back plain data results that I can further process, preferably without any other side effects.
What makes you think you can't ? Pass input events to the relevant Qt objects once per frame, tell it to render to an FBO and do whatever you want with the result.
> through a simple plain data API,
I'm working on large app made in Qt and the number of times where I call Qt functions taking Qt containers as arguments, eg QList or QVectors can be counted on the fingers of one hand. What do you have in mind for instance ?
> I don't think that is flexible or maintainable.
The number of reliable large applications based on frameworks certainly shows otherwise. Even in video games, could you cite more than five big AAA game in the last decade that were not based on UDK, CryEngine and its variants, or Unity3D ?
> I don't want to use a framework that takes over the process and the processes' I/O and the main loop,
That's what I was referring to when I mentioned code reusability. Event loops & IO have been abstracted away for a long time, yet people refuse to use these abstractions for reasons unknown to me and keep reinventing game loops in every game, instead of just referring to some lifecycle schema like Unity3D's (https://docs.unity3d.com/Manual/ExecutionOrder.html) or Qt's (http://doc.qt.io/qt-5/qtquick-visualcanvas-scenegraph.html). These schemas did not come out of thin air, but of years of experimenting on different categories of apps and seeing what works and what does not ; 99% of the time you don't need to deviate from them, especially if you're not making an AAA.
> This is my experience with Qt at least (as well as with CMake, for example).
I feel like we're living in a parallel world. Qt maintains API and ABI compatibility for major versions, the last breakage was in Qt 4 -> 5 transition 6 years ago. And a large part of the apps I use still have CMake 2.6 - 2.8 level buildscripts while we're at 3.10, and they still work as-is.
> Even in video games, could you cite more than five big AAA game in the last decade that were not based on UDK, CryEngine and its variants, or Unity3D?
It seems you are less informed than my first impression was. I did a few web searches, and the AAA titles using especially Unity seem to be far and far between. It's not good enough technically for top-notch performance (seems to require a garbage collector).
Also there are so many types of games that they cannot possibly supported by just two generic engines. For example, Open-World games need their own. Or military games like Call of Duty have their own. (And of course many Indie games have their own, as I said in the other comment).
Also most bigger publishers breed their own engines to save the fees for licencing a third party engine.
Well I had to do a little dashboard application and the interfacing from C++ to QML was... laborious, to say the least. It was quite hard to find the right magic words to do seemingly simple things like getting a list of dropdown items over to QML. If you don't have to work with Qt containers most of the time, I figure you have good abstractions in place. (So you're not working directly with Qt after all?) I wanted to do that too, but my employer wasn't happy with me not using enough QStrings and QStringLists and what not.
> Even in video games, could you cite more than five big AAA game in the last decade that were not based on UDK, CryEngine and its variants, or Unity3D?
I don't play many games, and if AAA means "graphically impressive but possibly not a conceptual innovation", then my answer would be "no". I would be hard pressed to quote 5 AAA games at all. (I sometimes play FIFA on a friend's PS3 (yes it's dull), and here we have the first exception. Whatever)
However I happen to "know" that many Indie game developers prefer to control their own codebase, that they know in and out, and that they can cut and trim and slice and dice, to try out new ideas. (This includes more commonly known titles like Super Meat Boy, Braid, The Witness).
> keep reinventing game loops
Why should I not "reinvent" a game loop? It's a trivial thing to do. No big deal. I'd rather do it myself than starting with a big preconceived framework that starts with words like "Awake", "OnEnable", "OnLevelWasLoaded", "OnApplicationPause" (What's a level? Why would I have such a thing?).
> I feel like we're living in a parallel world.
I would like my applications to last much longer than 6 years. And I would really be surprised if there were not more problems. Regarding CMake, I wasted >20h in multiple attempts fighting an existing CMake build system including a tangled mess of CMake scripts. It's really hard to understand and maintain. The documentation is not good, it doesn't try to teach you the underlying conceptual models. I then decided to just put my build description in a python file and generate the build system myself. 3h until it first worked, very little maintenance afterwards. Plus, I now have the flexibility to easily add more facets as the system evolves, and to easily derive other useful dev tools from the python structures. (Small downside, would possibly have to write more build system generators if there were multiple supported platforms. But while CMake makes some of this a no-brainer, it's almost never just "now compile for this other platform", and other aspects to porting get relatively harder with CMake).
What makes you think you can't ? Pass input events to the relevant Qt objects once per frame, tell it to render to an FBO and do whatever you want with the result.
> through a simple plain data API,
I'm working on large app made in Qt and the number of times where I call Qt functions taking Qt containers as arguments, eg QList or QVectors can be counted on the fingers of one hand. What do you have in mind for instance ?
> I don't think that is flexible or maintainable.
The number of reliable large applications based on frameworks certainly shows otherwise. Even in video games, could you cite more than five big AAA game in the last decade that were not based on UDK, CryEngine and its variants, or Unity3D ?
> I don't want to use a framework that takes over the process and the processes' I/O and the main loop,
That's what I was referring to when I mentioned code reusability. Event loops & IO have been abstracted away for a long time, yet people refuse to use these abstractions for reasons unknown to me and keep reinventing game loops in every game, instead of just referring to some lifecycle schema like Unity3D's (https://docs.unity3d.com/Manual/ExecutionOrder.html) or Qt's (http://doc.qt.io/qt-5/qtquick-visualcanvas-scenegraph.html). These schemas did not come out of thin air, but of years of experimenting on different categories of apps and seeing what works and what does not ; 99% of the time you don't need to deviate from them, especially if you're not making an AAA.
> This is my experience with Qt at least (as well as with CMake, for example).
I feel like we're living in a parallel world. Qt maintains API and ABI compatibility for major versions, the last breakage was in Qt 4 -> 5 transition 6 years ago. And a large part of the apps I use still have CMake 2.6 - 2.8 level buildscripts while we're at 3.10, and they still work as-is.