> There are JavaScript interpreters for microcontrollers (see Duktape and > Jerryscript). But those are designed to run on tens of *kilobytes* of RAM. > You > can't compare them to Qt, as they have special limitations to run that way. > For example, neither implementation supports "eval". I wonder if those tiny devices with tens or even hundreds of kilobytes RAM running Jerryscript would be already sufficient for a "QML light". I am not talking about QML GUIs, but rather simple sensor/actor applications consisting of few state machines and using one of the 1001 available communication stacks.
MCU vendors usually offer and praise their own C SDKs, but my experience so far is that it can take a very long time to achieve even simple applications and one has to write either a lot of boilerplate code or use fragile and obscure tools. QML has some powerful features that feel like a quantum leap when compared to C: - property bindings - easy component composition - signals, signal handlers - ... If we had nice QML modules like Qt Bluetooth and Qt Sensors available for tiny devices, I believe that application development would become very simple and convenient. I am making a few assumptions here: - the whole application structure would be static, no dynamic loading of components - bindings are resolved at build-time. - the application would be compiled to bytecode on the host before being flashed onto the target - the back-end of those modules would most likely not be Qt - it would be possible to deduce, which features the QML application actually uses so that unused functionality can be dropped at build-time. I would be interested in other opinions. Maybe I am on a completely wrong track here. Richard _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
