[Development] new "debugsupport" module and API

Ulf Hermann ulf.hermann at digia.com
Mon May 12 11:48:21 CEST 2014


we currently have several implementations of the QML debug protocol used 
to transmit data between a debugger or profiler and the application 
being debugged or profiled. I'm proposing a generalized "debugsupport" 
module to address various issues with those. In particular:

1. Code duplication

We currently have implementations of QPacketProtocol in:
- qtdeclarative/src/plugins/qmltooling/shared/
- qtdeclarative/tools/qmlprofiler
- qtquick1/src/declarative/debugger
- qt-creator/src/libs/qmldebug

We have differently named but functionally largely identical 
implementations of the qml debug client and connection in:
- qtdeclarative/tests/auto/qml/debugger/shared
- qtdeclarative/tools/qmlprofiler
- qtquick1/src/declarative/debugger
- qt-creator/src/libs/qmldebug

We also have 2 server implementations, in qtquick1 and qtdeclarative. 
The debug clients and servers share a lot of functionality regarding 
connection handling and notifying their plugins about various 
conditions. Those plugins for servers and clients can share the same 
base class as they all expose the same interface to the server or 
client. Currently we have 6 of those base classes.

2. Missing flexibility

Currently a TCP connection is used for any kind of debugging or 
profiling. This is potentially wasteful and dangerous as TCP has a 
certain overhead and the protocol itself doesn't care about security. 
Providing a connection over a QLocalSocket at least as an option seems 
to be a good idea.

The debug server is currently tied into QtQml, even though it has
technically nothing to do with QML. It's a general purpose tool
for interacting with an application over a defined interface. It should
live in a more appropriate place so that we can use it in other
contexts if the need arises.

3. Messy implementation

Many of the client implementations are badly written, potentially leak
memory, don't properly handle errors, expose too many details of the
underlying connection and provide subtly different interfaces to their

It's also a bad idea to specify the interface between the debug server
and client in terms of an arcane binary protocol full of magic numbers
and with a colorful history (e.g. the protocol version is unusable; we
practically never do service advertisement; in order to extend the 
protocol you can only add things to the end of messages, but you can 
never change any existing parts; service versions are transmitted as 
floats). Hiding the mess behind a clean C++ interface will make it much 
easier to work with and enables us to eventually replace the protocol 
with something less crazy.

The following changes create a debugsupport module with public API in 

I also have some WIP changes for qtdeclarative to use debugsupport:

And for QtCreator:

QtQuick1 will get the same treatment.

Ulf Hermann, Software Engineer - Digia, Qt

More information about the Development mailing list