Cómo crear nodos artificiales en QAbstractItemModel para QTreeView

Question

Mi pregunta es acerca de Qt y su QAbstractItemModel .

Tengo un mapa de cuerdas y dobles (std::map<stringclass, double>) que me gustaría que presente en un widget de Qt. Mientras que podría utilizar QTableView para eso, me gustaría aprovechar el hecho de que las llaves del mapa son de la forma "abc.def.ghi", donde puede haber múltiples cadenas que pueden comenzar con "abc.def" y más aún que comienzan con "abc".

Así que me gustaría configurar un modelo de datos de árbol para presentar los elementos de una QTreeView como

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

Las llaves de mi std::map son las hojas del árbol, donde todos los otros nodos serían construcciones temporales y auxiliares para apoyar el plegamiento para comodidad del usuario.

Por desgracia, la rowCount métodos, index, columnCount y data Tienes const modificadores, por lo que no se puede simplemente configurar una estructura de datos auxiliar para los encabezados dentro de mi QAbstractItemModel derivado y el cambio que estructura de datos en allí.

¿Cuál sería la mejor práctica para que? ¿Debo configuración otra capa de clase entre mi std::map y la QAbstractItemModel o hay una forma más inteligente de hacer esto?

---

Editar 1: El std::map puede cambiar mientras se muestra la QTreeView y utilizan, por lo que los nodos auxiliares podrían ser desechados y reconstruidos. Mi suposición es que la mejor manera de manejar esto es reestructurar la QAbstractItemModel - o debería lanzar simplemente que el modelo de distancia y asignar una nueva fabricarse de manera que la QTreeView ? En ese caso pude configuración todos los nodos del constructor sin ser molestado por la const-dad de los métodos, supongo.

Answer 1

Me analizar el mapa y crear una estructura de datos de árbol basado en él. Asegúrese de que sincronice el modelo cuando se cambia el mapa. Si este paso de sincronización se pone demasiado complicado es posible que desee almacenar los datos en una estructura de árbol desde el principio y convertido a un mapa cuando sea necesario.

Analizando el mapa sobre la marcha de las funciones de modelo parece una mala idea para mí, que te gustaría que estas funciones sean lo más rápido posible.

Answer 2

No veo cómo const modificadores sería realmente un problema.

Lo que los miembros de su derivado QAbstractItemModel le desee cambiar cuando rowCount, index, columnCount y métodos data se llaman? Que muy bien puede almacenar una referencia a su mapa, y calcular todo de ella. No hay necesidad de modificar el mapa mismo para extraer la información necesaria (por lo que puedo decir!).

Edición después EDIT1 y comentarios :
Si el mapa está destinada a ser modificada, lo utilizan como su estructura de base en su propia clase. Si no puede mantener una referencia a su mapa, porque la vida del modelo podría exceder del mapa, usar punteros inteligentes para asegurarse de que no suceda.