Solution la plus élégante / sûre / facile à stocker et à modifier (GUI) Une structure d'arbres semblable à un répertoire?

Question

J'ai un problème légèrement délicat à résoudre; imagine ça:

L'une de mes applications doit faire de la forte utilisation des scripts, donc mon idée était de fournir à l'utilisateur un moyen d'écrire des extraits de script et de les organiser dans une structure d'arbres de type répertoire. Cela ressemble beaucoup à des répertoires de code source avec des sous-répertoires et des fichiers source.

Classes de données / stockage

Le premier problème que je rencontre est que j'ai besoin de trouver un bon moyen de stocker toute la structure des arbres (sur le disque et dans l'application lors de l'exécution). Pour cela, j'avais ces idées:

1. Utilisez une classe dérivée QObject qui peut représenter l'arborescence à l'aide des fonctionnalités parent / enfants de QObject. De cette façon, je n'ai pas à me soucier de supprimer ces objets si les parents sont supprimés.
2. Utilisez une classe simple qui peut contenir une QLIST (sans pointeurs) d'enfants et quelques propriétés qui stockent les propriétés de chaque groupe / script.
3. Utilisez l'approche n ° 2, mais utilisez des pointeurs au lieu d'objets statiques - cela éviterait une copie inutile lorsque je dois passer un groupe ou une partie d'un arbre à une fonction, etc.
4. Utilisez un backend en direct dans une base de données SQLite (ou similaire) et interrogez-le au moment de l'exécution. Cela éviterait de charger tout l'arbre à la fois et de le garder dans RAM.
5. Utiliser un fichier plat et une structure de répertoire sur le système de fichiers; Bien que je pense que cela introduit plus de problèmes que nécessaire car il n'y a aucun moyen de stocker des méta-informations sur les objets.

Éditeur

Le prochain problème que je rencontre est le fait que l'utilisateur veut probablement modifier toute la structure de l'arborescence. Il veut cliquer sur un groupe ou un script, modifier le code de script et éventuellement faire glisser et déposer des répertoires et des scripts dans l'arborescence; Changeant ainsi la structure de l'arbre entier sur le chemin.

Cela soulève les problèmes suivants:

1. Si l'utilisateur ferme l'éditeur, il pourrait être une bonne idée de lui fournir un "Voulez-vous enregistrer les modifications?" dialogue. Un peu comme un éditeur de texte où vous avez accidentellement tapé quelque chose dans un document existant, mais vous quittez sans enregistrer les modifications. - Cela nécessiterait que nous modifiions une copie de l'arborescence entière et écrasez l'arborescence existante dans l'application en cas de besoin.
2. Autoriser le glisser-déposer pourrait être problématique ...
   • ... avec le stockage de l'approche n ° 1: Actuellement, il n'y a pas de bon moyen de changer l'ordre des enfants de Qobjects. Déplacer également des objets à l'exécution tandis que d'autres parties du programme peuvent y accéder n'est pas une bonne idée.
   • ... c'est plus facile avec stockage de l'approche n ° 2, puisque l'arbre entier est manipulé comme une seule valeur et qu'il n'y a pas d'enfants, je devrais bouger et rediffusion. La copie d'une partie de l'arbre copie automatiquement tous les enfants et ainsi de suite. Malheureusement, cela signifierait beaucoup de frais généraux et de perte de flexibilité (je devrais réécrire l'arbre entier sur le disque car je ne peux pas être sûr de ce qui a exactement changé).

Je vais probablement mettre à jour cette question un peu quand plus de choses me viennent à l'esprit, mais je suis vraiment curieux de savoir comment les autres résolvent ce problème. Toutes les suggestions et idées sont appréciées. :)

Answer 1

J'ai maintenant résolu le problème en limitant la profondeur de l'arbre à l'aide de classes dédiées. Cela signifie qu'il n'y a qu'une quantité limitée de profondeur d'arborescence qui doit être gérée, donc pour l'instant j'utilise simplement QTreeTreeWidget et quelques méthodes d'assistance qui permettent le tri, le glisser-déposer et d'autres fonctionnalités.

Answer 2

Je vous suggère de jeter un œil à QfilesystemModel pour de bonnes pratiques. Le modèle doit se mettre à jour à l'aide d'un fil séparé pour la réactivité de l'interface utilisateur, en gardant un cache, etc. Un modèle bien élevé devrait également faciliter votre travail sur l'éditeur.

J'irais également pour dériver QObject pour créer vos classes TreeItem. Un aproach de données partagé avec QsharedData pour une classe de base serait bien. J'aurais également une propriété pour sa commande. De cette façon, lorsque l'utilisateur glisse et laisse tomber ou modifie l'ordre d'une autre manière, vous avez un moyen de garder le contrôle. Étant donné que les données sont partagées, garder votre propre liste d'objets dans votre commande de performance aurait peu de coût.

Jetez également un œil à Modèle de modèle.