But wasn’t the scenegraph also developed for Qt? Qt… the C++ framework? It is not like it is a common practice for Qt to develop APIs in C++ that are not possible to use from C++, at least until now…
Not to mention there is an ample difference between “written especially for” and “written exclusively for”. Doing something for a specific reason doesn’t imply it is also exclusive to it. Atomic research was conducted especially to make an atomic bomb and drop it on innocent civilians, but luckily today this is not the only application – we also have clean nuclear power.
But I happen to know a common practice companies surely love to resort to – develop great features using C++ but “accidentally” left out the public interface to use those with C++ and only make it possible though their own language. Which is effectively using the API to promote a proprietary language by means of providing it with exclusive neat features.
I highly doubt locking away functionality can be justified for the sake of binary compatibility – all it takes to preserve it is a simple guideline to follow – keep classes the size of an int, dynamically allocate private data – and that’s about it…
I will be more more than willing to contribute, but the way things are right now keeps my hands tied. I sure would love if there were the resources I need to be able to implement my concept on top of the scenegraph. It is not like you need JS to resolve simple expressions, even without compilation to native a rudimentary VM machine would be much easier to implement than plugging in an entire JS engine. But what’s the point of doing that when the scenegraph can’t be used directly?
I never really got a straight a reasonable answer to the question “Why was the scenegraph implemented in a way that doesn’t allow standalone use and why there is no information on how to do that?” – and without a straight answer, I am forced to speculate, as much as I hate. I don’t see any good reason for this except for the sake of promoting QML – “If you like the features and performance, you have to use QML”.
Lets face it – the scenegraph is probably the best and most significant upgrade Qt has seen this past few years. And it just so happens that this entire feature, implemented in C++, has no public API to use with C++ and is instead locked out from direct use, and the only way to utilize it is to settle for QML…
You, much like many other people, seem to be trying to make this about me in some attempt to discredit it, like it is some personal whim that makes no sense, but once again I encourage you to go ahead and check the poll result. That thread is not about being able to instantiate existing QML components from C++, it is about the need of a modern hardware accelerated graphics API for C++, something currently absent from Qt, not because it doesn’t exist but because a deliberate decision was made not to allow it.
And that decision, believe it or not, is directly preventing contributions to Qt in this area. I myself have plenty of ideas, but if I have to implement my own scenegraph then why even bother using Qt and contributing my work to a framework that is forcing me to reinvent the wheel, because it doesn’t want me to be able to use the already existing wheel in that framework?
And I don’t think I am asking for much – even without a public API, a few examples how to use the scenegraph standalone through the private one will honestly suffice – how to put a scenegraph in a QWindow, create and attach a few example nodes in a simple example project without using any of the QML related classes. That’s all!
↧