¿La solución más elegante/segura/fácil para almacenar y editar (GUI) una estructura de árboles en forma de directorio?

Question

Tengo un problema un poco difícil de resolver; imagina esto:

Una de mis aplicaciones debe hacer un uso intensivo de las secuencias de comandos, por lo que mi idea era proporcionar al usuario una forma de escribir fragmentos de script y organizarlos en una estructura de árboles de directorio. Esto es muy similar a los directorios de código fuente con subdirectorios y archivos de origen.

Clases de datos/almacenamiento

El primer problema que encuentro es que necesito encontrar una buena manera de almacenar toda la estructura del árbol (en el disco y dentro de la aplicación en tiempo de ejecución). Por esto tenía estas ideas:

1. Use una clase derivada de QObject que pueda representar el árbol utilizando las características padre/niño de Qobject. De esta manera, no tengo que preocuparme por eliminar esos objetos si los padres son eliminados.
2. Use una clase simple que pueda contener una qlist (sin punteros) de niños y algunas propiedades que almacenan las propiedades de cada grupo/script.
3. Use el enfoque n. ° 2, pero use punteros en lugar de objetos estáticos; esto evitaría la copia inútil cuando tenga que pasar un grupo o parte de un árbol a una función, etc.
4. Use un backend en vivo en una base de datos SQLite (o similar) y consulte en tiempo de ejecución. Esto evitaría cargar todo el árbol a la vez y mantenerlo en RAM.
5. Use un archivo plano y una estructura de directorio en el sistema de archivos; Aunque creo que esto introduce más problemas de los necesarios porque no hay forma de almacenar meta información sobre objetos.

Editor

El siguiente problema que encuentro es el hecho de que el usuario probablemente quiera editar toda la estructura del árbol. Quiere hacer clic en un grupo o script, editar el código de script y posiblemente arrastrar y soltar directorios y scripts dentro del árbol; cambiando así la estructura de todo el árbol en el camino.

Esto plantea los siguientes problemas:

1. Si el usuario cierra el editor, podría ser una buena idea proporcionarle un "¿Quieres guardar los cambios?" diálogo. Al igual que un editor de texto donde accidentalmente escribió algo en un documento existente, pero renunció sin guardar los cambios. - Esto requeriría que editemos una copia de todo el árbol y sobrescriba el árbol existente dentro de la aplicación cuando sea necesario.
2. Permitir arrastrar y soltar podría ser problemático ...
   • ... con el Afecto de almacenamiento #1: Actualmente no existe una buena manera para cambiar el orden de los hijos de Qobjects. Además, mover objetos en tiempo de ejecución, mientras que otras partes del programa podrían acceder a ellos no es una buena idea.
   • ... esto es más fácil con Enfoque de almacenamiento #2, dado que todo el árbol se maneja como un solo valor y no hay niños, tendré que moverse y volver a ser parente. Copiar una parte del árbol copia automáticamente a todos los niños, etc. Desafortunadamente, esto significaría muchos gastos generales y pérdidas en flexibilidad (tendría que volver a escribir todo el árbol en el disco, ya que no puedo estar seguro de qué cambió exactamente).

Probablemente actualizaré esta pregunta un poco cuando se me ocurra más cosas, pero tengo mucha curiosidad por saber cómo otras personas resuelven este problema. Se agradecen cualquier sugerencia e ideas. :)

Answer 1

A estas alturas, resolví el problema limitando la profundidad del árbol usando clases dedicadas. Eso significa que solo hay una cantidad limitada de profundidad del árbol que debe manejarse, por lo que por ahora simplemente uso qtreetreewidget y algunos métodos auxiliares que permiten clasificar, arrastrar y soltar y otras características agradables.

Answer 2

Le sugiero que eche un vistazo a QfilesystemModel para obtener buenas prácticas. El modelo debe actualizarse utilizando un hilo separado para la capacidad de respuesta de la interfaz de usuario, manteniendo un caché, etc. Un modelo bien comportado también debe facilitar su trabajo en el editor.

También iría a derivar Qobject para crear sus clases de TreeItem. Un apresurado de datos compartidos con qshareddata para una clase base sería bueno. También tendría una propiedad para su orden. De esta manera, cuando el usuario se arrastra y cae o cambia el pedido de cualquier otra manera que tenga una forma de mantener el control. Dado que los datos se comparten, mantener su propia lista de objetos en su pedido de rendimiento tendría poco costo.

Además, eche un vistazo a Modelto.