> It sounds like an interesting project. > > I just wonder why you prefer "pure" Javascript over QML? It's not so > hard to expose C++ objects or classes to QML, depending on whether > you want to use pre-created objects or create instances via QML > declarations. Are there some JS examples which demonstrate why this > kind of code really needs to be procedural instead, perhaps to > describe an order of doing things, as opposed to declaring objects > which will then handle events from sensors or from users? >
There is a considerable number of things that cannot be done with the current extension mechanism. The C++ classes registed as QML types don't create JavaScript constructor functions, for example. This makes it impossible to add custom functionality by modifying their prototypes or to add "static" functions to the constructor object. There is no way to implement custom functions anyway, which was possible with QScriptEngine::newFunction(). Since moc doesn't support varargs, it is currently impossible to create a JS function that would take a variable number of arguments. And there is no setDefaultPrototype(). These are just a few illustrative examples. The extension mechanism in QML relies on the assumption that C++ classes are designed and written for QML use. Furthermore, it requires that these classes all derive from QObject. This is not true with existing toolkits such as Into. It is designed for C++ use, but the classes can be used from QML. Or rather could, if the interface wasn't a moving target. -- Topi Mäenpää Co-founder, Intopii intopii.com +358 40 774 7749 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
