[Gammaray-interest] GammaRay for UI testing automation

[Volker Krause]

On Sunday, 17 June 2018 04:31:53 CEST Christian Gagneraud wrote:
> On 15 June 2018 at 23:07, Volker Krause <volker.krause at kdab.com> wrote:
> > On Friday, 15 June 2018 05:12:53 CEST Christian Gagneraud wrote:
> >> On 14 June 2018 at 03:47, Volker Krause <volker.krause at kdab.com> wrote:
> >> The object query engine would then sit on top of the object tree and
> >> the meta object tree models.
> > 
> > Basically yes. There's a few details to keep in mind though when looking
> > at
> > the object hierarchy, as there is more than one:
> > - QObject parent-child hierarchy, ie. the object tree
> > - Widget hierarchy: almost the same as QObject parent-child but with
> > special cases regarding top-level windows and layouts. GammaRay doesn't
> > really do this correctly, if you e.g. compare to the tree in Qt Designer
> > - Qt Quick item hierarchy: that's actually very different from the QObject
> > parent-child relation, you find a large amount of top-level items in the
> > QObject tree that actually belong somewhere else. The Qt Quick item model
> > in GammaRay shows this mostly correctly.
> 
> So maybe a query should have a "target namespace", to select which
> object hierarchy to use (with a default to QObject).
> I think it would be  mistake if the query engine had it's own models.
> Sitting on top of the existing object hierarchies means that the
> engine would benefit from (or inherit the flaws of) Gammaray's
> existing ones.
> There's as well QGraphicsScene, and Qt3D that are other specialised
> hierarchy views.
> 
> Are all specialised Object tree implemented as ObjectFilterProxyModel?
> I saw that this is how WidgetTreeModel works.

Actually the widget model is probably the last one to still use this approach, 
it's what leads to the incorrect hierarchy described above. All the other 
specialized models (Quick, QGV, Qt3D, etc) redo the entire hierarchy handling. 
That's a lot more work, but it gives us full control over the result.

> > Meta objects OTOH are generally easier as they have a unique name, and can
> > possibly even be looked up directly via QMetaType. There is the nasty
> > exception of dynamic meta objects that have been recreated at runtime
> > though, breaking the uniqueness assumption. GammaRay ignores that problem
> > in most places.
> 
> Unfortunately not all QObject have their PointerToQObject registered.
> 
> >> A naive approach would be to scan both trees for each query, but i'm
> >> not sure this will be efficient.
> > 
> > That's how I would start as well, we might need to add caches or indexes
> > to
> > speed this up eventually though. As those need to be maintained on changes
> > to the objects it's potentially rather costly too though.
> 
> Yes, so i'm more and more thinking that the query engine should have
> it's own structures on top of the existing ones.
> Something that not only would allow for fast lookup, but would
> actually make the code easier to write.
> 
> Object query by class name and object name are the most simple and
> IMHO the most common ones.
> 
> For example, the query engine could keep a few lookup tables by
> monitoring the MetaObjectModel and ObjectListModel. Eg.
> class name to QMO, object name to QO list and QMO to alive QO list.
> But then you would need reverse lookup support to access model
> indexes, unless these tables store the values as model index, but they
> would have to be persistent, so it might induce a high cost...

Right, but the reverse mapping is already present inside the models, they 
should be able to quickly go from ObjectId to QModelIndex, e.g. for 
synchronizing selection when picking objects. IIRC that's exposed via match() 
to the outside atm.

> BTW, any other class/model you think I should look at?

Seeing your other post, I think you found everything :)

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/cbe4ae5e/attachment.p7s>