[Development] The place of QML

André Pönitz andre.poenitz at mathematik.tu-chemnitz.de
Thu May 10 01:26:09 CEST 2012

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.

More information about the Development mailing list