Qt 5.12 aura enfin un composant TableView pour Qt Quick

Cela faisait longtemps qu’on l’attendait. Depuis ses débuts, Qt Quick ne dispose pas d’une vue pour des tableaux. Il a fallu attendre Qt Quick Controls pour voir une première itération arriver, avec Qt 5.1 (2013), mais avec quelques problèmes de performance.
Qt Quick Controls 2 n’a jamais fourni de remplacement, depuis 2016, mais ce n’est plus important : avec Qt 5.12, la version qui devrait sortir en novembre prochain, Qt Quick proposera, de base, un composant pour afficher des tableaux.

Ce composant fonctionnera de manière similaire à ListView, mais avec la gestion de multiples colonnes. On disposera ainsi d’une gestion complète des modèles (que ce soit des ListModel ou des tableaux JavaScript), même s’il faut régulièrement repasser au C++ pour écrire ses propres modèles avec QAbstractItemModel (un composant TableModel est en cours d’écriture, mais il ne sera vraisemblablement pas disponible en même temps). TableView est implémenté par-dessus Flickable, ce qui signifie que le tableau affiché n’est absolument pas limité par la zone disponible à l’écran, on peut le faire défiler dans tous les sens. Chaque élément est affiché à l’aide d’un délégué spécifique ; pour des raisons de performance, contrairement à ListView, les délégués sont réutilisés quand un item sort de la vue — mais ce mécanisme n’est pas prévu pour être invisible au développeur. En particulier, tout qui oserait stocker un état dans un délégué (une très mauvaise idée, le délégué ne devant servir qu’à l’affichage ou à l’édition d’une valeur, pas plus) ne le verrait pas remis à zéro lors de la réutilisation de l’instance du délégué : il faut utiliser les signaux TableView.onPooled et TableView.onReused pour cela.

https://youtu.be/n_fYQa5til8

Ce composant est assez flexible et autonome. Par exemple, par défaut, la largeur des colonnes est décidée en fonction de la largeur des éléments à y stocker (la propriété implicitWidth), qui est supposée constante à travers la colonne. Pour plus de personnalisation, les développeurs de TableView ont prévu un mécanisme un peu particulier, une fonction de rappel qui, en fonction de l’indice de la ligne ou de la colonne, renvoie la taille à lui assigner. Par exemple :

Code:

---

1 2 3 4 5 6 7 8 9 10

TableView { anchors.fill: parent clip: true model: myQAbstractTableModel delegate: Rectangle {}   columnWidthProvider: function (column) { return column % 2 ? 100 : 200 } rowHeightProvider: function (row) { return row % 2 ? 100 : 200 } }

---

À part cela, le composant est assez rudimentaire. Il n’y a pas de transition personnalisable lors de l’ajout de colonne ou de ligne, par exemple. Les en-têtes ne sont pas encore implémentés. Le composant DelegateChooser devrait également faire partie des fonctionnalités à court terme (il est déjà dans le module Qt.labs.qmlmodels 1.0, donc sans garantie de stabilité) : il permet d’utiliser plusieurs délégués par tableau (par défaut, il n’y en a qu’un seul qui correspond à une ligne entière) et, par exemple, d’assigner un délégué à une colonne.

Source : TableView.

Qt 5.12 : le nouveau composant TableView pour Qt Quick a une très bonne performance,
grâce à une réutilisation des délégués

Qt 5.12 a une nouveauté majeure du côté Qt Quick : un composant TableView pour afficher des tableaux. Les mauvaises langues diront qu’il était temps, les autres se souviendront du composant TableView de Qt Quick Controls 1… et de son horrible performance. Même dans un tableau relativement petit (trente colonnes), il est impossible de défiler à grande vitesse dans les lignes :

https://youtu.be/tw12l4eAZY0

L’ancienne implémentation n’a jamais été prévue pour de bonnes performance. Elle était implémentée en QML par-dessus ListView, un composant prévu pour d’autres usages : en fait, simplement afficher une liste. Cette première itération de TableView mettait une série de cellules par élément de la liste (comme délégué), ce qui effectivement ressemble à un tableau. Sauf que… TableView, premier du nom, alloue un nouveau délégué chaque fois qu’un nouvel item entre dans la vue et désalloue ceux qui en sortent, parce que ListView fonctionne ainsi. En défilant rapidement, on doit donc allouer un très grand nombre d’objets assez complexes qui ne sont presque jamais affichés.

La nouvelle implémentation part de zéro. Elle est effectuée en C++ par-dessus le composant Flickable, qui fournit une interface pour faire défiler un composant (de haut en bas, de gauche à droite et dans les autres sens). Elle n’alloue que les lignes et les colonnes visibles à l’écran et réutilise les délégués autant que possible, en évitant de remettre les délégués à zéro pour limiter le nombre de signaux émis. Toute l’API est prévue pour une bonne performance plutôt qu’un usage déclaratif : par exemple, pour donner la taille d’une colonne, cela ne peut plus se faire au niveau d’une colonne (propriété width de TableViewColumn), mais bien à l’aide d’une fonction définie pour le tableau entier. Cette manière de faire est bien plus pratique pour des centaines ou des milliers de colonnes — la cible du nouveau composant. Le résultat est saisissant, en comparaison.

https://youtu.be/PQLS6MXKyek

Source : TableView performance.