Why?
One of the interesting things about QML is that it leverages OOP property semantics of QObject to drive its declarative workflow.
How?
We attach into any QObject the developer requests and monitor it (and optionally all it’s children).
To gather the information we need, we will collect information for every property and connect to the property’s notification signal to see when it changes.
What?
This is the repository:https://phabricator.kde.org/source/kobjecttracking/.
This allows us to see:
- Spurious property change notifications
- Property changing bursts (i.e. same property changing values repeatedly in a short amount of time)
- How a change in a value can have an effect on other properties
At the moment we have two ways of inspecting an application:
On one hand we have warnings that allow us know specific things and even add breakpoints to the sore points. The warnings at the moment look like this:
repeated value ScrollView_QMLTYPE_43(0x5648c6d97b50) width QVariant(double, 320) 8 times
repeated value Kirigami::BasicTheme(0x5648c6986ac0) backgroundColor QVariant(QColor, QColor(ARGB 1, 0.988235, 0.988235, 0.988235)) 11 times
Additionally, we have a timeline view output from tracking. You can see an example of plasmashell run here.
Future
An idea would be to integrate automatically ModelTest, so if a QAbstractItemModel is found, a ModelTest instance is attached that makes sure the model is true to its promises.
Another thing that bothers me is that we are forced to compile it into the application. If we could make it possible to have processes attached or start the application somewhat automatically (like GammaRay does, wink-wink) we would ease the adoption of these tools.
What do you think? Do you think it’s useful?
Feedback very welcome.
