[Gammaray-interest] Fwd: GammaRay for UI testing automation

[Christian Gagneraud]

Bummer, just realised that the discussion left the ML, sorry about that.

---------- Forwarded message ----------
From: Christian Gagneraud <chgans at gmail.com>
Date: 17 June 2018 at 14:31
Subject: Re: [Gammaray-interest] GammaRay for UI testing automation
To: Volker Krause <volker.krause at kdab.com>


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.

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

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

>> So to start with, I think the minimal working example I should aim at
>> is something like:
>> Query: class = "Foo", name = "Bar", baz = True.
>> Meaning: an object of class "Class" (or derived), with an objectName
>> "Bar" and a property "baz" set to True.
>> Result: I haven't figure out what should I return from a query, a list
>> of Protocol::ObjectAddress?
>
> ObjectAddress is the numerical identifier for a GammaRay-owned object
> registered with the communication system, what you are more likely looking for
> is ObjectId, that's a handle for a server-side object owned by the target
> application. When returning that to the server for further processing you need
> to be careful before actually dereferencing that, ie. you need to hold the
> Probe::objectLock() and verify it with Probe::isValidObject() first. And while
> this will not crash then you might still be vulnerable to the ABA problem, if
> the target application does something unfortunate with that object. Should
> work good enough for normal somewhat long-living objects though for a start.

Got it, thanks for the explanations.

> There was a discussion at the Qt Contributor Summit earlier this week about
> re-basing GammaRay on top of Qt Remote Objects, which would give us all that
> for free. However that would mean giving up support for older Qt versions, and
> that's about half of the current user base.

And i'm one of them! We're currently stuck to Qt-5.6, but there's on
going discussion to move to 5.9 or even 5.12.
Maybe for Gammaray-ng ... If Qt RO could be coupled with the upcoming
"Python for Qt", there would be even more potential.

Thanks,
Chris