[Gammaray-interest] XPath and ObjectTreeModel

[Christian Gagneraud]

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.

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.
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...

Chris

[1] lot of calls to ObjectXmlNodeModel's nextFromSimpleAxis(),
attributes(), kind(), name(), ...