[Gammaray-interest] GammaRay for UI testing automation
Volker Krause
volker.krause at kdab.com
Tue Jun 19 09:56:09 CEST 2018
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.
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/20180619/5516991e/attachment.p7s>
More information about the Gammaray-interest
mailing list