Versioned QML classes are not recognized by their public type name

Bug #1341671 reported by Cris Dywan
32
This bug affects 7 people
Affects Status Importance Assigned to Milestone
Autopilot Qt Support
Confirmed
High
Unassigned

Bug Description

Basic example "qmldir" file illustrating the problem:

module Ubuntu.Components
Button 0.1 Button.qml
#version 1.1
Button 1.1 Button11.qml

In Autopilot doing something like this

pushButton = self.main_view.select_single('Button', objectName='push_button')

will unexpectedly fail depending on the "import" being used in the QML code.

Tags: elopio toolkit
Revision history for this message
Leo Arias (elopio) wrote :
Revision history for this message
Leo Arias (elopio) wrote :
Revision history for this message
Leo Arias (elopio) wrote :

The attached files show what happens when the types are versioned.
You'll need the latest toolkit on utopic, and you can open them with qmlscene -testability and introspect with autopilot vis.

Leo Arias (elopio)
Changed in autopilot-qt:
status: New → Confirmed
tags: added: elopio toolkit
Changed in autopilot-qt:
importance: Undecided → High
summary: - Versioned QML classes are no longer recognized by their public type name
+ Versioned QML classes are nt recognized by their public type name
summary: - Versioned QML classes are nt recognized by their public type name
+ Versioned QML classes are not recognized by their public type name
Revision history for this message
Nekhelesh Ramananthan (nik90) wrote :

I have found a reliable way of reproducing this issue which I have described below. I do not know why it happens unfortunately but hope this helps in figuring out why.

Open the code attached in Qtc, and open the SimplePage.qml file. The file is essentially something as simple as,

import QtQuick 2.0
import Ubuntu.Components 1.1

Page {
    id: simplePage
    objectName: "simplePage"

    //property string testProperty: "woohoo"

    title: i18n.tr("Simple")

    Label {
        anchors.centerIn: parent
        text: "run"
    }
}

If you check in autopilot3 vis, you will notice that the object tree shows this as "Page11". However, if you uncomment the testProperty line and then check again in autopilot3 vis, you will see it appear as "SimplePage". Somehow the property declared in the property change the public object type name.

I have this exact same issue with the Clock App AP tests.

Revision history for this message
Thomi Richards (thomir-deactivatedaccount) wrote :

Hi Nekhelesh,

The issue you have discovered is actually a separate problem. The Qml processor contains an optimisation where, if you don't specialise your type with a property, it will use the parent type name. That's why, in your example, you get 'Page11' (the name of the parent type) or 'simplePage' depending on wherther the property is enabled or not.

Cheers,

Revision history for this message
Tim Peeters (tpeeters) wrote :

This is bugging us in the SDK team when we try to add/remove functionality from UITK in newer versions.

For example, right now I want to clean up MainView to remove toolbar support (and have better code) in MainView 1.2, but if I create MainView12.qml then the autopilot tests that select the MainView by component type will break.

We had a workaround for this where we instead would create a directory for a new version and add a file 12/MainView.qml but that is obviously a workaround, and it does not work for all cases (including the cases I am dealing with now). It requires in 12/MainView.qml to use an import of Ubuntu.Componets in order to be able to use other components of UITK inside MainView. However this needs to be a named import due to https://bugreports.qt-project.org/browse/QTBUG-27645 and a named import cannot be used to define a property Toolkit.Toolbar toolbar for example, so this approach doesn't work.

Revision history for this message
Tim Peeters (tpeeters) wrote :

Probably it is also useful to have a look at qml types that are exported from c++, not from a qml file.

Revision history for this message
Leo Arias (elopio) wrote :

We have three more bugs related to the way we select qml types from autopilot:
https://bugs.launchpad.net/autopilot/+bug/1210265
https://bugs.launchpad.net/autopilot/+bug/1337004
https://bugs.launchpad.net/autopilot/+bug/1350532

If we fix all of them plus this bug, it would mean that we have a nice, flexible and future-proof way to select elements from the QML tree and assign custom proxy objects to them.

Revision history for this message
Tim Peeters (tpeeters) wrote :

This AP issue is blocking us from adding some new features in Ubuntu.Components 1.2 because we cannot have different qml files for different versions of components. This is the first thing we like to fix after AP supports versioned QML classes: https://bugs.launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/+bug/1369939

Revision history for this message
Cris Dywan (kalikiana) wrote :

I don't know of this is sensible for Autopilot to use (I haven't seen exactly how it's done there) but for the API tooling I found that QMetaObject can be listed from a QQmlComponent created from QML source code, based on exported type names. The WIP branch for that is https://code.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/newJsonApiCheck. This is based on the same way qmlplugindump works behind the scenes.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.