[Gammaray-interest] XPath and ObjectTreeModel

[Volker Krause]

Very cool!

On Monday, 18 June 2018 05:07:00 CEST Christian Gagneraud wrote:
> Hi there,
> 
> Quick email to report about my week-end experiments/gross hacks.
> 
> I created 2 classes:
>  - ObjectQueryEngine
>  - ObjectXmlNodeModel (derived from QSimpleXmlNodeModel)
> 
> The ObjectQueryEngine as a member of Probe that only requires access
> to the ObjectTreeModel.
> ObjectXmlNodeModel is an adaptor to ObjectTreeModel that makes the
> tree looks like the following XML structure:
> <objects>
>  <ClassNameA property0="value" ...>
>    <ClassNameB property0="value" .../>
>    ...
>  </ClassNameA>
>  ...
> </objects>
> 
> The main function of ObjectQueryEngine is "query(const QString
> &xpath)", returned value is QList<ObjectId>.
> 
> The outline of query() looks like:
> 
> QXmlItemResult result;
> QXmlQuery query(QXmlQuery::XPath20);
> query.setQuery(xpath);
> QMutexLocker lock(Probe::objectLock());
> ObjectXmlNodeModel model(m_probe->objectTreeModel());
> query.setfocus(model->root());
> query.evaluateTo(&result);
> while (result.hasNext()) {
>   // dump result item on stdout
> }
> return QList<ObjectId>(); // not implemented
> 
> I didn't bother with remote interface, instead i fired an hard-coded
> xpath with a QTimer::singleShot(2000) at the end of the probe
> constructor.
> 
> ObjectTreeModel is dynamic, ObjectXmlNodeModel is just a stateless
> adaptor to access the tree model. QXmlQuery walks the XmlNoneModel as
> needed, so the object tree is not allowed to change during the
> execution of the query and the processing of the results. Hence the
> need to lock the objectLock for the whole duration of the query.
> 
> The execution of a simple query such as '//QWidget' caused the whole
> object tree to be scanned (might cause perf issues [1]). For some
> reason I couldn't get '//QLabel[@text="..."]' working, but not a big
> deal for now.

Btw, how did you do the property access? QMetaProperty directly or using the 
PropertyAdaptor system that's used by the property model?

QMetaProperty is probably good enough in most cases and comparatively light-
weight, OTOH PropertyAdaptor also allows access to non QMO properties, grouped 
QML properties and property container values, for example.

> Conclusion:
> XPath query looked great at first,but i'm not sure that Qt XML pattern
> is appropriate here (at least using my approach), as a 'QWidget'
> element will never match a 'QToolButton' element.I cannot think of any
> *simple and efficient* solution to make Qt XML pattern be aware of the
> C++ inheritance.

Indeed, that's a major difference to XML, and a crucial one here. It's 
probably not even just about being able to match to all sub-classes, but also 
about being able to express that difference in the query (ie. give me all 
QLabel-ish objects vs. give me direct QWidget instances), both have valid use-
cases.

> Nonetheless, it would be nice to see how (in)efficient this solution
> is. Obviously the complexity is at least NxM, where NxM would roughly
> be the dimension of the table if we flatten the tree into a table, not
> even counting the number of each Element's attributes (=
> QMetaProperty)...
> I think a better solution would be to replace the walk+match with
> something based on dynamic lookup tables...

Right, without any form of indexing the lookup speed would be linear. Being 
able to restrict the search to a specific hierarchy would help a bit, as you 
typically have a lot less widgets than overall objects for example, but 
ultimately that's not changing the linear complexity.

Maintaining lookup tables however would also incur a considerable cost (N log 
N I guess), so the interesting factor is probably the ratio of object lookups 
to object changes, hard to predict and very dependent on the application and 
specific use-case...

Regards,
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4664 bytes
Desc: not available
URL: <http://mail.kdab.com/pipermail/gammaray-interest/attachments/20180618/02c6fbc2/attachment-0001.p7s>