Наиболее элегантное/безопасное/простое решение для хранения и редактирования (GUI), похожая на каталог, структуру дерева?

Question

У меня есть немного сложная проблема для решения; Представьте себе:

Одно из моих приложений должно использовать сценарии, поэтому моя идея заключалась в том, чтобы предоставить пользователю способ писать фрагменты сценариев и организовать их в структуре деревьев, похожей на каталог. Это очень похоже на каталоги исходного кода с подкаталогами и исходными файлами.

Классы данных/хранение

Первая проблема, с которой я сталкиваюсь, заключается в том, что мне нужно найти хороший способ сохранить всю структуру дерева (на диске и в приложении во время выполнения). Для этого у меня были эти идеи:

1. Используйте класс, полученный в Qubject, который может представлять дерево, используя функции родителей/дочерних людей Qobject. Таким образом, мне не нужно беспокоиться о удалении этих объектов, если их родители будут удалены.
2. Используйте простой класс, который может содержать QLIST (без указателей) детей и несколько свойств, которые хранят свойства каждой группы/сценария.
3. Используйте подход № 2, но используйте указатели вместо статических объектов - это позволило бы избежать бесполезного копирования, когда я должен передать группу или часть дерева в функцию и т. Д.
4. Используйте живую бэкэнд в базу данных SQLite (или аналогичной) и запросите его во время выполнения. Это избежало бы загрузки всего дерева одновременно и удерживать его в оперативной памяти.
5. Используйте плоский файл и структуру каталога в файловой системе; Хотя я думаю, что это приводит к большему количеству проблем, чем необходимо, потому что нет способа хранить мета -информацию об объектах.

редактор

Следующая проблема, с которой я сталкиваюсь, - это тот факт, что пользователь, вероятно, хочет отредактировать всю структуру дерева. Он хочет нажать на группу или сценарий, отредактировать код сценария и, возможно, перетаскивать каталоги и сценарии внутри дерева; таким образом изменяя структуру всего дерева на пути.

Это поднимает следующие проблемы:

1. Если пользователь закрывает редактор, это может быть хорошей идеей, чтобы дать ему «Хотите сохранить изменения?» диалог Очень похоже на текстовый редактор, где вы случайно ввели что -то в существующий документ, но вы уходите, не сохраняя изменения. - Это потребует, чтобы мы редактировали копию всего дерева и перезаписывали существующее дерево в приложении, когда это необходимо.
2. Разрешение перетаскивания может быть проблематичным ...
   • ... с Хранение подхода № 1: В настоящее время нет хорошего способа изменить порядок детей Qobjects. Также перемещение объектов во время выполнения, в то время как другие части программы могут получить к ним доступ, не является хорошей идеей.
   • ... это легче с Хранение подхода № 2, поскольку все дерево обрабатывается как единое значение, и нет детей, которые я не должен был двигаться и повторно родителей. Копирование части дерева автоматически копирует всех детей и так далее. К сожалению, это означало бы много накладных расходов и гибкости потери (мне пришлось снова написать все дерево на диск, так как я не могу быть уверен, что именно изменилось).

Я, наверное, немного обновлю этот вопрос, когда мне на голову придет больше вещей, но мне очень любопытно, как другие люди решают эту проблему. Любые предложения и идеи ценятся. :)

Answer 1

К настоящему времени я решил проблему, ограничив глубину дерева, используя выделенные классы. Это означает, что существует только ограниченное количество глубины дерева, которое необходимо обработать, поэтому сейчас я просто использую QtreetreeRewidget и несколько вспомогательных методов, которые позволяют сортировать, перетаскивать и выпадать и другие приятные функции.

Answer 2

Я бы посоветовал вам взглянуть на Qfilesystemmodel для хорошей практики. Модель должна обновлять себя, используя отдельный поток для отзывчивости пользовательского интерфейса, сохранить кэш и так далее. Хорошо ведущая модель также должна облегчить вашу работу над редактором.

Я также пошел бы на получение QObject для создания ваших классов TreeItem. Было бы неплохо было позаботиться об общим данным с QsharedData для базового класса. У меня также была собственность для его заказа. Таким образом, когда пользователь перетаскивает и бросает или меняет заказ любым другим способом, у вас есть способ сохранить контроль. Поскольку данные обмениваются, хранить свой собственный список объектов в вашем заказе на производительность, будет иметь небольшую стоимость.

Также взгляните на Modeltest.