Modèles et vues en Qt Quick

La plupart des applications ont besoin de formater et d'afficher des données. Qt Quick possède la notion de modèles, de vues et de délégués pour afficher les données. Ils modulent la visualisation des données afin de permettre au développeur ou au concepteur de contrôler les différents aspects des données. Un développeur peut remplacer une vue en liste par une vue en grille en modifiant peu les données. De même, l'encapsulation d'une instance de données dans un délégué permet au développeur de dicter la manière de présenter ou de traiter les données.

• Modèle - contient les données et leur structure. Il existe plusieurs types QML pour créer des modèles.
• Vue - un conteneur qui affiche les données. La vue peut afficher les données dans une liste ou une grille.
• Délégué - dicte comment les données doivent apparaître dans la vue. Le délégué prend chaque unité de données dans le modèle et l'encapsule. Les données sont accessibles par l'intermédiaire du délégué. Le délégué peut également réécrire des données dans des modèles modifiables (par exemple, dans le gestionnaire onAccepted d'un site TextField).

Pour visualiser les données, liez la propriété model de la vue à un modèle et la propriété delegate à un composant ou à un autre type compatible.

Affichage de données avec des vues

Les vues sont des conteneurs pour des collections d'éléments. Elles sont riches en fonctionnalités et peuvent être personnalisées pour répondre à des exigences de style ou de comportement.

Un ensemble de vues standard est fourni dans l'ensemble de base des types graphiques Qt Quick:

• ListView - organise les éléments dans une liste horizontale ou verticale
• GridView - organise les éléments dans une grille à l'intérieur de l'espace disponible
• PathView - organiser les éléments sur un chemin
• TableView - organiser les données d'un site QAbstractTableModel dans un tableau
• TreeView - classe les données d'un QAbstractItemModel dans un arbre

Ces types ont des propriétés et des comportements qui leur sont propres. Consultez leur documentation respective pour plus d'informations.

En outre, Qt Quick Controls contient quelques vues et délégués supplémentaires qui sont stylisés en fonction du style de l'application, par exemple HorizontalHeaderView et VerticalHeaderView.

Décoration des vues

Les vues permettent une personnalisation visuelle grâce à des propriétés de décoration telles que les propriétés header, footer et section. En liant un objet, généralement un autre objet visuel, à ces propriétés, les vues peuvent être décorées. Un pied de page peut inclure un type de Rectangle montrant des bordures ou un en-tête affichant un logo en haut de la liste.

Supposons qu'un club particulier souhaite décorer sa liste de membres aux couleurs de sa marque. Une liste de membres se trouve dans une page model et la page delegate affichera le contenu du modèle.

ListModel {
    id: nameModel
    ListElement { name: "Alice" }
    ListElement { name: "Bob" }
    ListElement { name: "Jane" }
    ListElement { name: "Harry" }
    ListElement { name: "Wendy" }
}
Component {
    id: nameDelegate
    Text {
        required property string name
        text: name
        font.pixelSize: 24
        width: ListView.view.width
    }
}

Le club peut décorer la liste des membres en liant des objets visuels aux propriétés header et footer. L'objet visuel peut être défini en ligne, dans un autre fichier ou dans un type Component.

ListView {
    anchors.fill: parent
    clip: true
    model: nameModel
    delegate: nameDelegate
    header: bannercomponent
    footer: Rectangle {
        width: parent.width; height: 30;
        gradient: clubcolors
    }
    highlight: Rectangle {
        color: "lightgray"
    }
}

Component {     //instantiated when header is processed
    id: bannercomponent
    Rectangle {
        id: banner
        width: parent.width; height: 50
        gradient: clubcolors
        border {color: "#9EDDF2"; width: 2}
        Text {
            anchors.centerIn: parent
            text: "Club Members"
            font.pixelSize: 32
        }
    }
}
Gradient {
    id: clubcolors
    GradientStop { position: 0.0; color: "#8EE2FE"}
    GradientStop { position: 0.66; color: "#7ED2EE"}
}

Gestion de la souris et du toucher

Les vues gèrent le glisser-déposer de leur contenu, mais elles ne gèrent pas l'interaction tactile avec les délégués individuels. Pour que les délégués réagissent à l'entrée tactile, par exemple pour définir le site currentIndex, un site MouseArea doté de la logique de gestion tactile appropriée doit être fourni par le délégué.

Notez que si highlightRangeMode est défini sur StrictlyEnforceRange, l'index courant sera affecté par le glissement ou le claquement de la vue, puisque la vue veillera toujours à ce que currentIndex se trouve dans la plage de mise en évidence spécifiée.

Sections de la vue en liste

ListView Les contenus peuvent être regroupés en sections, dans lesquelles les éléments de la liste sont étiquetés en fonction de leurs sections. En outre, les sections peuvent être agrémentées de délégués.

Une liste peut contenir une liste indiquant les noms des personnes et l'équipe à laquelle elles appartiennent.

ListModel {
    id: nameModel
    ListElement { name: "Alice"; team: "Crypto" }
    ListElement { name: "Bob"; team: "Crypto" }
    ListElement { name: "Jane"; team: "QA" }
    ListElement { name: "Victor"; team: "QA" }
    ListElement { name: "Wendy"; team: "Graphics" }
}
Component {
    id: nameDelegate
    Text {
        required property string name
        text: name;
        font.pixelSize: 24
        anchors.left: parent.left
        anchors.leftMargin: 2
    }
}

Le type ListView possède la propriété section attached qui permet de combiner des types adjacents et apparentés dans une section. Le site section.property détermine les propriétés du type de liste à utiliser comme sections. La propriété section.criteria peut dicter la manière dont les noms des sections sont affichés et la propriété section.delegate est similaire à la propriété delegate des vues.

ListView {
    anchors.fill: parent
    model: nameModel
    delegate: nameDelegate
    focus: true
    highlight: Rectangle {
        color: "lightblue"
        width: parent.width
    }
    section {
        property: "team"
        criteria: ViewSection.FullString
        delegate: Rectangle {
            color: "#b0dfb0"
            width: parent.width
            height: childrenRect.height + 4
            Text { anchors.horizontalCenter: parent.horizontalCenter
                font.pixelSize: 16
                font.bold: true
                text: section
            }
        }
    }
}

Délégués de vues

Les vues ont besoin d'un délégué pour représenter visuellement un élément dans une liste. Une vue visualisera chaque liste d'éléments selon le modèle défini par le délégué. Les éléments d'un modèle sont accessibles via la propriété index et les propriétés de l'élément.

Component {
    id: petdelegate
    Text {
        id: label
        font.pixelSize: 24
        text: index === 0 ? type + " (default)" : type

        required property int index
        required property string type
    }
}

Positionnement des délégués de vue

Le type de vue détermine la manière dont les éléments sont positionnés. ListView positionne les éléments en ligne droite, en fonction de orientation, tandis que GridView peut les disposer dans une grille à deux dimensions. Il n'est pas recommandé de lier directement x et y, car le comportement de mise en page de la vue aura toujours la priorité sur toute liaison positionnelle.

Accès aux vues et aux modèles à partir de délégués

La vue en liste à laquelle le délégué est lié est accessible à partir du délégué via la propriété ListView.view. De même, la propriété GridView GridView.view est accessible aux délégués. Le modèle correspondant et ses propriétés sont donc accessibles via ListView.view.model. En outre, tous les signaux ou méthodes définis dans le modèle sont également accessibles.

Ce mécanisme est utile lorsque vous souhaitez utiliser le même délégué pour un certain nombre de vues, par exemple, mais que vous voulez que les décorations ou d'autres caractéristiques soient différentes pour chaque vue, et que vous souhaitez que ces différents paramètres soient des propriétés de chacune des vues. De même, il peut être intéressant d'accéder à certaines propriétés du modèle ou de les afficher.

Dans l'exemple suivant, le délégué affiche la propriété language du modèle, et la couleur de l'un des champs dépend de la propriété fruit_color de la vue.

Rectangle {
     width: 200; height: 200

    ListModel {
        id: fruitModel
        property string language: "en"
        ListElement {
            name: "Apple"
            cost: 2.45
        }
        ListElement {
            name: "Orange"
            cost: 3.25
        }
        ListElement {
            name: "Banana"
            cost: 1.95
        }
    }

    Component {
        id: fruitDelegate
        Row {
            id: fruit
            required property string name
            required property real cost
            Text {
                text: " Fruit: " + fruit.name
                color: fruit.ListView.view.fruit_color
            }
            Text {
                text: " Cost: $" + fruit.cost
            }
            Text {
                text: " Language: " + fruit.ListView.view.model.language
            }
        }
    }

    ListView {
        property color fruit_color: "green"
        model: fruitModel
        delegate: fruitDelegate
        anchors.fill: parent
    }
}

Modèles

Les données sont fournies au délégué par l'intermédiaire de rôles de données nommés auxquels le délégué peut se lier. Voici un site ListModel avec deux rôles, type et âge, et un site ListView avec un délégué qui se lie à ces rôles pour afficher leurs valeurs :

import QtQuick

Item {
    width: 200
    height: 250

    ListModel {
        id: myModel
        ListElement { type: "Dog"; age: 8; noise: "meow" }
        ListElement { type: "Cat"; age: 5; noise: "woof" }
    }

    component MyDelegate : Text {
        required property string type
        required property int age
        text: type + ", " + age
        // WRONG: Component.onCompleted: () => console.log(noise)
        // The above line would cause a ReferenceError
        // as there is no required property noise,
        // and the presence of the required properties prevents
        // noise from being injected into the scope
    }

    ListView {
        anchors.fill: parent
        model: myModel
        delegate: MyDelegate {}
    }
}

Dans la plupart des cas, vous devez utiliser des propriétés obligatoires pour transmettre les données du modèle à vos délégués. Si un délégué contient des propriétés requises, le moteur QML vérifiera si le nom d'une propriété requise correspond à celui d'un rôle de modèle. Si c'est le cas, cette propriété sera liée à la valeur correspondante du modèle.

Dans de rares cas, vous pouvez vouloir transférer les propriétés du modèle via le contexte QML plutôt qu'en tant que propriétés requises. Si aucune propriété obligatoire n'est présente dans votre délégué, les rôles nommés sont fournis en tant que propriétés du contexte :

import QtQuick

Item {
    width: 200; height: 250

    ListModel {
        id: myModel
        ListElement { type: "Dog"; age: 8 }
        ListElement { type: "Cat"; age: 5 }
    }

    Component {
        id: myDelegate
        Text { text: type + ", " + age }
    }

    ListView {
        anchors.fill: parent
        model: myModel
        delegate: myDelegate
    }
}

Les propriétés de contexte sont invisibles pour les outils et empêchent le compilateurQt Quick d'optimiser votre code. Elles rendent plus difficile le raisonnement sur les données spécifiques attendues par votre délégué. Il n'existe aucun moyen de remplir explicitement le contexte QML à partir de QML. Si votre composant s'attend à ce que des données soient transmises via le contexte QML, vous ne pouvez l'utiliser qu'aux endroits où le contexte adéquat est disponible par des moyens natifs. Il peut s'agir de votre propre code C++ ou des implémentations spécifiques des éléments environnants. Inversement, les propriétés requises peuvent être définies de différentes manières à partir de QML ou par des moyens natifs. Par conséquent, le passage de données via le contexte QML réduit la possibilité de réutilisation de vos composants.

En cas de conflit de noms entre les propriétés du modèle et celles du délégué, il est possible d'accéder aux rôles en utilisant le nom qualifié du modèle. Par exemple, si un type Text avait des propriétés (non obligatoires) de type ou d'âge, le texte de l'exemple ci-dessus afficherait les valeurs de ces propriétés au lieu des valeurs de type et d'âge de l'élément de modèle. Dans ce cas, les propriétés auraient pu être référencées comme model.type et model.age afin que le délégué affiche les valeurs des propriétés de l'élément de modèle. Pour que cela fonctionne, vous devez exiger une propriété model dans votre délégué (à moins que vous n'utilisiez des propriétés contextuelles).

Un rôle index spécial contenant l'index de l'élément du modèle est également disponible pour le délégué. Notez que cet index est mis à -1 si l'élément est supprimé du modèle. Si vous vous liez au rôle d'index, assurez-vous que la logique prend en compte la possibilité que l'index soit à -1, c'est-à-dire que l'élément ne soit plus valide. (En général, l'élément sera bientôt détruit, mais il est possible de retarder la destruction du délégué dans certaines vues par le biais d'une propriété attachée delayRemove ).

Rappelez-vous que vous pouvez utiliser des entiers ou des tableaux comme modèle :

Repeater {
    model: 5
    Text {
        required property int modelData
        text: modelData
    }
}

Repeater {
    model: ["one", "two", "three"]
    Text {
        required property string modelData
        text: modelData
    }
}

Ces modèles fournissent un élément de données unique et anonyme à chaque instance du délégué. L'accès à cet élément de données est la principale raison d'utiliser modelData, mais d'autres modèles fournissent également modelData.

L'objet fourni par le rôle de modèle possède une propriété dont le nom est vide. Cette propriété anonyme contient les modelData. En outre, l'objet fourni via le rôle de modèle possède une autre propriété appelée modelData. Cette propriété est obsolète et contient également les données de modèle.

En plus du rôle de modèle, un rôle modelData est fourni. Le rôle modelData contient les mêmes données que la propriété modelData et la propriété anonyme de l'objet fourni via le rôle model.

Les différences entre le rôle de modèle et les divers moyens d'accès aux données de modèle sont les suivantes :

• Les modèles qui n'ont pas de rôle nommé (comme les entiers ou un tableau de chaînes) ont leurs données fournies via le rôle modelData. Dans ce cas, le rôle modelData ne contient pas nécessairement un objet. Dans le cas d'un modèle à nombre entier, il contiendrait un nombre entier (l'index de l'élément actuel du modèle). Dans le cas d'un tableau de chaînes, il contiendra une chaîne. Le rôle du modèle contient toujours un objet, mais sans aucune propriété pour les rôles nommés. Le modèle contient toujours ses propriétés modelData et anonymes habituelles.
• Si le modèle n'a qu'un seul rôle nommé, le rôle modelData contient les mêmes données que le rôle nommé. Il ne s'agit pas nécessairement d'un objet et il ne contient pas le rôle nommé en tant que propriété nommée, comme c'est habituellement le cas. Le rôle de modèle contient toujours un objet avec le rôle nommé comme propriété, ainsi que les propriétés modelData et anonymous dans ce cas.
• Pour les modèles à rôles multiples, le rôle modelData n'est fourni que comme propriété obligatoire, et non comme propriété contextuelle. Ceci est dû à la rétrocompatibilité avec les anciennes versions de Qt.

La propriété anonyme sur le modèle vous permet d'écrire proprement des délégués qui reçoivent à la fois les données de leur modèle et le nom du rôle auquel ils doivent réagir en tant que propriétés de l'extérieur. Vous pouvez fournir un modèle sans rôle ou avec un seul rôle nommé, et une chaîne vide comme rôle. Dans ce cas, une liaison qui accède simplement à model[role] donnera les résultats escomptés. Il n'est pas nécessaire d'ajouter du code spécial pour ce cas.

QML fournit plusieurs types de modèles de données parmi l'ensemble intégré de types QML. En outre, les modèles peuvent être créés avec Qt C++, puis mis à la disposition de QQmlEngine pour être utilisés par les composants QML. Pour plus d'informations sur la création de ces modèles, consultez les articles Using C++ Models with Qt Quick Views et creating QML types.

Le positionnement des éléments d'un modèle peut être réalisé à l'aide d'une page Repeater.

Modèle de liste

ListModel est une simple hiérarchie de types spécifiés en QML. Les rôles disponibles sont spécifiés par les propriétés ListElement.

ListModel {
    id: fruitModel

    ListElement {
        name: "Apple"
        cost: 2.45
    }
    ListElement {
        name: "Orange"
        cost: 3.25
    }
    ListElement {
        name: "Banana"
        cost: 1.95
    }
}

Le modèle ci-dessus a deux rôles, name et cost. Ils peuvent être liés par un délégué ListView, par exemple :

ListView {
    anchors.fill: parent
    model: fruitModel
    delegate: Row {
        id: delegate
        required property string name
        required property real cost

        Text { text: "Fruit: " + delegate.name }
        Text { text: "Cost: $" + delegate.cost }
    }
}

ListModel fournit des méthodes pour manipuler le site ListModel directement via JavaScript. Dans ce cas, le premier élément inséré détermine les rôles disponibles pour toutes les vues qui utilisent le modèle. Par exemple, si une page ListModel vide est créée et remplie par JavaScript, les rôles fournis par la première insertion sont les seuls rôles qui seront affichés dans la vue :

ListModel { id: fruitModel }
    ...
MouseArea {
    anchors.fill: parent
    onClicked: fruitModel.append({"cost": 5.95, "name":"Pizza"})
}

Lorsque l'on clique sur MouseArea, fruitModel aura deux rôles, le coût et le nom. Même si d'autres rôles sont ajoutés, seuls les deux premiers seront traités par les vues utilisant le modèle. Pour réinitialiser les rôles disponibles dans le modèle, appelez ListModel::clear().

Modèle XML

XmlListModel permet de construire un modèle à partir d'une source de données XML. Les rôles sont spécifiés via le type XmlListModelRole. Le type doit être importé.

import QtQml.XmlListModel

Le modèle suivant a trois rôles, title, link et pubDate:

XmlListModel {
     id: feedModel
     source: "http://rss.news.yahoo.com/rss/oceania"
     query: "/rss/channel/item"
     XmlListModelRole { name: "title"; elementName: "title" }
     XmlListModelRole { name: "link"; elementName: "link" }
     XmlListModelRole { name: "pubDate"; elementName: "pubDate" }
}

La propriété query spécifie que XmlListModel génère un élément de modèle pour chaque <item> dans le document XML.

La démo RSS News montre comment XmlListModel peut être utilisé pour afficher un flux RSS.

Modèle d'objet

ObjectModel contient les éléments visuels à utiliser dans une vue. Lorsqu'un ObjectModel est utilisé dans une vue, la vue n'a pas besoin de délégué car le ObjectModel contient déjà le délégué visuel (éléments).

L'exemple ci-dessous place trois rectangles colorés dans une vue ListView.

import QtQuick 2.0
import QtQml.Models 2.1

Rectangle {
    ObjectModel {
        id: itemModel
        Rectangle { height: 30; width: 80; color: "red" }
        Rectangle { height: 30; width: 80; color: "green" }
        Rectangle { height: 30; width: 80; color: "blue" }
    }

    ListView {
        anchors.fill: parent
        model: itemModel
    }
}

Les entiers comme modèles

Un nombre entier peut être utilisé comme modèle contenant un certain nombre de types. Dans ce cas, le modèle n'a pas de rôle de données.

L'exemple suivant crée un site ListView avec cinq éléments :

Item {
    width: 200; height: 250

    Component {
        id: itemDelegate

        Text {
            required property int index
            text: "I am item number: " + index
        }
    }

    ListView {
        anchors.fill: parent
        model: 5
        delegate: itemDelegate
    }

}

Instances d'objets en tant que modèles

Une instance d'objet peut être utilisée pour spécifier un modèle avec un seul type d'objet. Les propriétés de l'objet sont fournies en tant que rôles.

L'exemple ci-dessous crée une liste avec un seul élément, montrant la couleur du texte myText. Notez l'utilisation de la propriété model.color entièrement qualifiée pour éviter tout conflit avec la propriété color du type Text dans le délégué.

Rectangle {
    width: 200; height: 250

    Text {
        id: myText
        text: "Hello"
        color: "#dd44ee"
    }

    Component {
        id: myDelegate

        Text {
            required property var model
            text: model.color
        }
    }

    ListView {
        anchors.fill: parent
        anchors.topMargin: 30
        model: myText
        delegate: myDelegate
    }
}

Modèles de données C++

Les modèles peuvent être définis en C++, puis mis à la disposition de QML. Ce mécanisme est utile pour exposer à QML des modèles de données C++ existants ou des ensembles de données complexes.

Pour plus d'informations, consultez l'article Using C++ Models with Qt Quick Views.

Modèles de tableau

Vous pouvez utiliser des tableaux JavaScript et divers types de listes QML comme modèles. Les éléments de la liste seront disponibles en tant que modèle et données de modèle selon les règles décrites ci-dessus : Les données singulières telles que les entiers ou les chaînes de caractères sont disponibles en tant que données de modèle singulières. Les données structurées telles que les objets JavaScript ou les QObjects sont disponibles en tant que modèle structuré et données de modèle.

Les rôles individuels du modèle sont également mis à disposition si vous les demandez en tant que propriétés requises. Comme nous ne pouvons pas savoir à l'avance quels objets apparaîtront dans un tableau, toute propriété requise dans un délégué sera remplie, éventuellement avec une coercion de undefined vers le type requis. Les rôles des modèles individuels ne sont cependant pas disponibles via le contexte QML. Ils éclipseraient toutes les autres propriétés du contexte.

Répétiteurs

Les répétiteurs créent des éléments à partir d'un modèle pour les positionneurs, en utilisant les données d'un modèle. La combinaison des répétiteurs et des positionneurs est un moyen facile de disposer de nombreux éléments. Un élément Repeater est placé à l'intérieur d'un positionneur et génère des éléments que le positionneur qui l'entoure arrange.

Chaque Repeater crée un certain nombre d'éléments en combinant chaque élément de données d'un modèle, spécifié à l'aide de la propriété model, avec l'élément modèle, défini en tant qu'élément enfant dans le Repeater. Le nombre total d'éléments est déterminé par la quantité de données contenues dans le modèle.

L'exemple suivant montre un répéteur utilisé avec un élément Grid pour organiser un ensemble d'éléments Rectangle. L'élément Repeater crée une série de 24 rectangles que l'élément Grid doit positionner dans une disposition de 5 par 5.

import QtQuick

Rectangle {
    width: 400
    height: 400
    color: "black"

    Grid {
        x: 5
        y: 5
        rows: 5
        columns: 5
        spacing: 10

        Repeater {
            model: 24
            Rectangle {
                id: delegate

                required property int index

                width: 70
                height: 70
                color: "lightgreen"

                Text {
                    text: delegate.index
                    font.pointSize: 30
                    anchors.centerIn: parent
                }
            }
        }
    }
}

Le nombre d'éléments créés par un Repeater est défini par sa propriété count. Il n'est pas possible de définir cette propriété pour déterminer le nombre d'éléments à créer. Au lieu de cela, comme dans l'exemple ci-dessus, nous utilisons un nombre entier comme modèle.

Pour plus de détails, voir le document QML Data Models.

Si le modèle est une liste de chaînes de caractères, le délégué est également exposé à la propriété habituelle en lecture seule modelData qui contient la chaîne de caractères. Voici un exemple :

Column {
    Repeater {
        model: ["apples", "oranges", "pears"]
        Text {
            required property string modelData
            text: "Data: " + modelData
        }
    }
}

Il est également possible d'utiliser un délégué comme modèle pour les éléments créés par un Repeater. Ceci est spécifié à l'aide de la propriété delegate.

Modification des données du modèle

Toutes les vues concernées ont une propriété appelée delegateModelAccess qui détermine si et comment vous pouvez modifier les données du modèle à partir du délégué. Dans la plupart des cas, vous devez lui attribuer la valeur DelegateModel.ReadWrite. Cela permettra à votre délégué de modifier les données du modèle de la manière la plus souple possible. Vous pouvez également lui attribuer la valeur DelegateModel.ReadOnly si vous ne souhaitez pas que le délégué modifie les données du modèle.

Le tableau suivant décrit en détail toutes les valeurs que la propriété peut contenir.

Certains modèles sont des objets avec des identités indépendantes que la vue référence. L'objet original est la seule source de vérité pour la création de délégués. Il n'est pas copié. Ces modèles seront visiblement mis à jour lors de l'écriture par l'intermédiaire des délégués.

D'autres modèles n'ont pas d'identité indépendante et sont copiés lors de leur affectation à la vue. Pour ces modèles, seuls les éléments internes de la vue sont mis à jour lors de l'écriture par l'intermédiaire du délégué. Le modèle original reste inchangé.

En général, les types d'objets QML ont des identités indépendantes, alors que les types de valeurs QML n'en ont pas. Ainsi, ListModel, tout ce qui est dérivé de QAbstractItemModel, ainsi qu'une instance unique d'un type d'objet ou une liste d'instances de types d'objets seront mis à jour lorsqu'ils sont transmis en tant que modèle et écrits par le délégué. Cependant, les tableaux JavaScript, les listes de types de valeurs ou les nombres simples ne sont pas mis à jour lorsque vous modifiez les données du modèle par l'intermédiaire du délégué.

En outre, lorsque vous implémentez votre propre modèle C++, vous devez implémenter setData pour recevoir toutes les mises à jour transmises par les délégués.

Supposons qu'un modèle C++ basé sur QAbstractItemModel qui met en œuvre la méthode setData soit enregistré en tant que type QML nommé EditableModel. Les données peuvent alors être écrites dans le modèle de la manière suivante :

ListView {
    anchors.fill: parent
    model: EditableModel {}

    // Make sure that changes to the required property are propagated
    delegateModelAccess: DelegateModel.ReadWrite

    delegate: TextEdit {
        required property string edit

        width: ListView.view.width
        height: 30
        text: edit
        Keys.onReturnPressed: edit = text
    }
}

Vous pouvez également modifier les données du modèle en manipulant l'objet model comme suit :

ListView {
    anchors.fill: parent
    model: EditableModel {}
    delegate: TextEdit {
        required property QtObject model

        width: ListView.view.width
        height: 30
        text: model.edit
        Keys.onReturnPressed: model.edit = text
    }
}

Pour plus d'informations, consultez l'article Using C++ Models with Qt Quick Views.

Utilisation des transitions

Les transitions peuvent être utilisées pour animer les éléments qui sont ajoutés, déplacés ou retirés d'un positionneur.

Les transitions pour l'ajout d'éléments s'appliquent aux éléments créés dans le cadre d'un positionneur, ainsi qu'à ceux qui sont reparentés pour devenir des enfants d'un positionneur.

Les transitions pour la suppression d'éléments s'appliquent aux éléments d'un positionneur qui sont supprimés, ainsi qu'à ceux qui sont retirés d'un positionneur et qui se voient attribuer de nouveaux parents dans un document.