You know that I do appreciate your work to make QML easier to use. However, I am still not convinced that a custom language (especially one that does not fit _that_ seamlessly to C++) is needed at all.
Well, that's the main point then. Any language that does the object composition in a simpler way than connecting n+1 signals and slots is going to require some way of telling it what types are available. If you'd rather keep connecting signals and slots in C++, by all means do so. I'm all in favor of having a public C++ API for QtQuick.
However, please recognize that the classic way of setting up a widget hierarchy usually includes a lot of new and delete, as well as initialization of properties and connecting the same properties' change signals to the same setter functions you used for initialization. There are a lot of ways to mess this up that simply aren't possible in QML. Plus, the actual code that _does_ all this (in contrast to the code that just declares types) will be much simpler and easier to read in QML. That is the other side of this particular trade-off.
regards, Ulf _______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
