On Wed, May 09, 2012 at 02:38:24PM +0100, Philip Ashmore wrote: > If I could debug a Qml application the same way I can debug > html5/JavaScript it would help> Qml uptake a lot. > > This would require a Qml document object model (DOM) and a > debugger capable of inspecting Qml, JavaScript and c++. > > Is this possible already or is this one of the "Qml tools" > being developed?
Let's leave the question open to the ones who have some insight in the matter. Judging from the discussion so far I am sure you will get very convincing answers. Still, a few comments from my side. Qt Creator currently allows you to run a QML/JS and a C++ debugger in a kind of time-division multiplexing manner side-by-side, while trying to appear to the user as a monolithic debugger as much as possible. Breakpoints in either QML/JS or C++ code are hit, and continuing execution behaves orderly as if there was a homogeneous debuggee. However, all stepping and data inspection is essentially limited to one world at a time. If you are in QML/JS, the C++ data is not visible, and single-stepping remains on the QML/JS side, and vice- versa. This is sort of sufficient in the cases of "very thin QML Gui which can't possibly be wrong, plus a fat C++ core" and "small or not-existant C++ core which can't possibly be wrong, plus a fat QML/JS Gui". Note that this excludes the case "non-trivial gui plus non-trivial core." These limitations are kind of intrinsic to the "hybrid runtime" approach we have with the current incarnation of QML. They can theoretically be compensated by a bit of tinkering on a case-by- case base targeting individual combinations of C++ toolchain (at least the ones with "incompatible" debuggers like gcc and msvc), and QML "backend" implementations (e.g. v1/v2). In practice, there are some additional restrictions imposed by the individual tools. E.g. cdb's ability to call functions in the running process is rather limited compared to gdb's, so if the JS engine does not freely give direct access to its data but requires function calls you are stuck. About a year ago I had "cross stepping" (i.e. "Step into" on the QML1/JS side into a function implemented in C++ would end up in the implementation on the C++ side, with the C++ debugger active) in a sort-of-working state under "laboratory conditions." As this was based on direct access to internals of the script engine and some gdb trickery on the C++ side, moving that to QML2 would take about half of the total effort again, plus a bit extra for Mac gdb, plus a multiple of this for cdb. And that is "only" covering stepping. And it will break again with the next nontrivial backend change. A viable and maintainable solution from the debugging point of view would be to _not_ have a (noticable) hybrid at runtime, i.e. to target a setup where _all_ applications fall into either the "(almost) QML only" or "(almost) compiled only" categories mentioned above. That's where ideas like "a complete QML API" or "compiled QML" come into play. Andre' _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development