Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. QML and Qt Quick
  4. QML Loader and loaded item context. Is it a feature or a bug?
QtWS25 Last Chance

QML Loader and loaded item context. Is it a feature or a bug?

Scheduled Pinned Locked Moved QML and Qt Quick
6 Posts 4 Posters 5.8k Views
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • A Offline
    A Offline
    Algirdasss
    wrote on last edited by
    #1

    Hi everybody,

    when experimenting with QML I came up to one question. It seems that when QML Loader element loads a component, items within this component can't access properties defined in the loaders' parent and below. Normally QML items form "Context Hierarchy" and you can access properties, defined in "lower" items (parent or parents' parent or etc). But if you use Loader, the only way to access properties in the lower hierarchy levels is property binding.

    Just take a look at the sample code:
    @import QtQuick 1.1

    Rectangle {
    width: 460
    height: 360

    ListModel{
        id: personList
        ListElement{ name: "Algirdas" ; age: 29 }
        ListElement{ name: "Tadas" ; age: 29 }
        ListElement{ name: "Milda" ; age: 2 }
        ListElement{ name: "Akvile" ; age: 28 }
        ListElement{ name: "Rasa" ; age: 29 }
    }
    
    Rectangle{
        height: 200
        width: 200
    
        anchors.centerIn: parent
    
        color: "gray"
    
        Component{
            id: itemDelegate
            Text {
                // If I would write here just "name" or "rowModel.name", it would fail! I can access
                // only properties, defined in the Loader element itself
                text: rowModel2.name
            }
        }
    
        ListView{
            anchors.fill: parent
            model: personList
    
    
    
            delegate: Item {
                height: 30
                width: parent.widthr
    
                property variant viewHolder: ListView.view
                property variant rowIndex: index
                property variant rowModel: model
    
                Row{
                    anchors.fill: parent
                    spacing: 10
                    Loader{
                        // We have to use extra property binding to allow access for the loaded component
                        property variant rowModel2: rowModel
                        sourceComponent: itemDelegate
                    }
                    Text {
                        // This works fine because we do not use Loader here
                        text: name
                    }
                }
            }
        }
    }
    

    }
    @

    Is it a bug? Or a security feature that if you load a component, it can't have uncontrolled access to properties lower in the element hierarchy? Even if it is a feature, there is no proper explanation in QML Loader docs.

    It is very annoying!!! Actually I stepped on this when tried to use TableView from the upcoming QtQuick Desktop Components. In the TableView implementation Loader is used to load custom cell delegates (that can be defined by the user). And in this delegate you don't have access to all the roles of the model that you may need.

    1 Reply Last reply
    0
    • C Offline
      C Offline
      chrisadams
      wrote on last edited by
      #2

      It just sounds like a bug.
      There have been other cases where the instantiated component wasn't properly parented (for example, header component in a visual item model, IIRC).

      Have you tested it with QtQuick2? It's entirely possible that it was fixed there but not in QtQuick1.

      Cheers,
      Chris.

      1 Reply Last reply
      0
      • A Offline
        A Offline
        Algirdasss
        wrote on last edited by
        #3

        Tried with Qt 5.0 release. The same issue.
        It's a bit strange. A guy who is developing QtQuick Desktop Components came up to the same issue when writing TableView. He is using multiple property bindings to pass data to delegates loaded by the Loader. No complains came from him.

        1 Reply Last reply
        0
        • C Offline
          C Offline
          chrisadams
          wrote on last edited by
          #4

          Please file a bug report. It might be intentional (since the component created by the Loader is kind of separate to the context within which the loader exists, as it is managed by the Loader element itself - so conceptually its parent isn't the component higher in the scope chain...) but I think it's probably just a bug.

          Cheers,
          Chris

          1 Reply Last reply
          0
          • J Offline
            J Offline
            Jens
            wrote on last edited by
            #5

            It was intentional and do not assume there were no complaints from my side. :)

            The current behavior was introduced in Qt Quick 1.1 and it is here to stay. So for now you will have to forward the properties that you want to have available in your component scope explicitly. There are som valid arguments for that approach, such as to make the loaded components a bit more less coupled and insular.

            That said, the behavior is not going to change back at this point but you could file a suggestion to add an optional setting in Loader which results in the old behavior. I have no idea what to call the property or enumeration though.

            1 Reply Last reply
            0
            • M Offline
              M Offline
              mlvljr
              wrote on last edited by
              #6

              This is exactly what http://qt-project.org/doc/qt-5.0/qtquick/qml-qtquick2-loader.html#using-a-loader-within-a-view-delegate tells about :)

              Moving the sub-delegate inside the parent delegate, or to a separate file, should make it work.
              With the Desktop Components example that was mentioned, it should be the same.

              1 Reply Last reply
              0

              • Login

              • Login or register to search.
              • First post
                Last post
              0
              • Categories
              • Recent
              • Tags
              • Popular
              • Users
              • Groups
              • Search
              • Get Qt Extensions
              • Unsolved