[Gammaray-interest] GammaRay for UI testing automation

[Christian Gagneraud]

On 19 June 2018 at 19:56, Volker Krause <volker.krause at kdab.com> wrote:
> On Tuesday, 19 June 2018 06:17:25 CEST Christian Gagneraud wrote:
>> On 19 June 2018 at 11:46, Christian Gagneraud <chgans at gmail.com> wrote:
>> > On 18 June 2018 at 19:50, Volker Krause <volker.krause at kdab.com> wrote:
>> >> 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:
>> >>> 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.>
>> > OK, I see. So all I need is a QAstractItemModel to access the object
>> > hierarchy, all implementations respecting the promise of providing a
>> > name and a type for each node.
>> > And I need to sort out how to access the property extensions models...
>> > That all sound generic and beautiful (and I like it), but it doesn't
>> > help with class hierarchy.
>> > Anyway i'll stick to the qobject tree for now, and will try to only
>> > use the generic/standard interface as much as i can.
>>
>> OK, i think i got it, the object broker is the central place for
>> gammaray objects, models, and selection models.
>> the model names i'm after are:
>> com.kdab.GammaRay.MetaObjectBrowserTreeModel
>> com.kdab.GammaRay.MetaObjectBrowser.properties
>> com.kdab.GammaRay.ObjectInspectorTree
>> com.kdab.GammaRay.ObjectInspector.properties
>>
>> Interesting, will try to twiddle with that! ;)
>
> Yep, that's the easiest way to get to the existing models. The *.properties
> models are the instances of AggregatedPropertyModel that are in the property
> tab on the right side of the corresponding tool. Using those should work in
> theory, but there's one big downside: you need to change the selection of the
> corresponding object model to update their content, which is fairly expensive.
> Might still be a good approach for prototyping, as you can see what the query
> system "sees" live in the GammaRay client then. We can still use a dedicated
> server-side only model later, or even use the internals of
> AggregatedPropertyModel (ie. PropertyAdaptor) directly.

Indeed, but for my experiments, I think it's OK. I'm still making my
head around the code, and I think it will help me understand how
gammaray works.
Will report as soon as I get meaningful results.

Thanks,
Chris

PS: I'm sorry for spamming your inbox, but gmail seems to keep
ignoring this is a ML.