Comment créer des nœuds artificiels dans QAbstractItemModel pour QTreeView

Question

ma question est sur Qt et son QAbstractItemModel .

J'ai une carte de chaînes et doubles (std::map<stringclass, double>) que je voudrais présenter dans un widget Qt. Alors que je pouvais utiliser QTableView pour cela, je voudrais exploiter le fait que les clés de la carte sont de forme « abc.def.ghi » où il peut y avoir plusieurs chaînes qui peuvent commencer par « abc.def » et plus encore qui commencent par « abc ».

Je voudrais installer un modèle de données d'arbre pour présenter les éléments dans un QTreeView comme

(-) abc
    |--(-)def      
          |--ghi    3.1415
          |--jkl    42.0815
    |--(+)pqr
    |--(+)xyz

Les clés de mon std::map sont les feuilles de l'arbre, où tous les autres noeuds seraient des constructions temporaires et auxillary pour soutenir le pliage pour la commodité de l'utilisateur.

Malheureusement, les méthodes rowCount, index, columnCount et data ont const modificateurs, donc je ne peux pas configurer simplement une structure de données pour les en-têtes auxillary l'intérieur de mon QAbstractItemModel dérivé et modifier cette structure de données à l'intérieur.

Quelle serait la meilleure pratique pour cela? Dois-je configurer une autre couche de classe entre mon std::map et le QAbstractItemModel ou est-il façon plus intelligente de le faire?

---

Edit 1: Le std::map peut changer pendant que le QTreeView est représenté et utilisés, de sorte que les nœuds auxillary pourraient être jetés et reconstruit. Mon hypothèse est que la meilleure façon de gérer cela est de restructurer le QAbstractItemModel - ou devrais-je simplement jeter ce modèle loin et attribuer un nouveau constructred un à l' QTreeView ? Dans ce cas, je pourrais mettre en place tous les noeuds du constructeur sans être dérangé par le const-ness des méthodes, je suppose.

Answer 1

J'analyser la carte et créer une structure de données d'arbre sur cette base. Assurez-vous de synchroniser le modèle lorsque vous changez la carte. Si cette étape de synchronisation est trop compliqué, vous pouvez stocker vos données dans une structure arborescente depuis le début et se convertir à une carte si nécessaire.

Parsing la carte à la volée dans les fonctions du modèle semble être une mauvaise idée à moi, vous voudriez que ces fonctions le plus rapidement possible.

Answer 2

Je ne vois pas comment les modificateurs const-serait vraiment un problème.

Ce que les membres de votre QAbstractItemModel voudriez-vous derivate modifier quand rowCount, index, columnCount et les méthodes de data sont appelés? Vous pouvez très bien stocker une référence à votre carte, et tout calculer de lui. Pas besoin de modifier la carte elle-même pour en extraire les informations nécessaires (pour autant que je peux dire!).

EDIT après EDIT1 et commentaires :
Si votre carte est lié à modifier, l'utiliser comme structure de base dans votre propre classe. Si vous ne pouvez pas garder une référence à votre carte, car la durée de vie du modèle pourrait dépasser la carte de, utiliser des pointeurs intelligents pour vous assurer qu'il ne se produise pas.