Древовидные модели в Pyside

Question

Возможно, я просто думаю об этом все неправильно, но мне кажется странным, что , чтобы иметь рабочую древовидную модель в Qt, нужно обернуть данные в класс предметов.

Во всех примерах, которые мне удалось найти, каждая модель, созданная для QTreeView, требовала реализации пользовательского класса Node или TreeItem (часто типа (объекта)). Это меня поражает по ряду причин:

a) Не все ли дело, что модель сможет напрямую извлекать данные? Класс Node или TreeItem выглядит как дополнительный багаж.

b) даже если для древовидного представления был необходим специальный класс item/node, почему бы этот класс не быть каким-то QObject? Большинство реализаций узла, которые я видел, имеют набор методов/атрибутов get/set parent/child; но похоже, что использование QObject будет иметь все, что уже встроено, так почему бы не использовать это?

Моя интуиция (что может быть неправильно) говорит мне, что если мы обнаружим, что нам нужен дополнительный класс Node для реализации древовидной модели, это из-за либо пробела в дизайне фреймворка Qt ..., либо непонимания Это.

Я смутно знаю QStandardItem и QStandardItemModel, но я спрашиваю, почему они являются частью QtGui, а не QtCore, так как другие модели & modelItems. Группировка этих классов с QtGui выглядит так: модель & смешивается. Тем не менее, я также не понимаю, почему они тоже находятся в QtGui, поскольку они не наследуются от каких-либо классов QtGui (они исходят из QtCore).

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

Спасибо!

Answer 1

Осуществив многочисленные модели данных на основе QAbstractItemModel на протяжении многих лет (десятилетий?) Я понимаю ваше разочарование, однако ...

иметь рабочую модель дерева в Qt, нужно обернуть данные в класс предмета.

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

a) Не все ли дело, что модель может напрямую извлекать данные? Класс Node или TreeItem выглядит как дополнительный багаж.

Вы можете непосредственно получить/установить данные с помощью QAbstractItemModel::data и QAbstractItemModel::setData

б) даже если специальный класс элемента/узла требовались для просмотра дерева, почему бы этот класс некоторое вид QObject? Большинство реализаций узла, которые я видел, имеют набор методов/атрибутов get/set parent/child; но похоже, что использование QObject будет иметь все, что уже встроено, так почему бы не использовать это?

A QObject - довольно существенная вещь.Учитывая, что модель может иметь (десятки?) Тысяч строк и каждая строка может иметь несколько столбцов, нетрудно заметить, что принудительное наследование каждой «ячейки» наследуется от QObject, возможно, не так хорошо масштабируется.

Я смутно осознает QStandardItem и QStandardItemModel, но спрашиваю себя, почему они являются частью QtGui и не QtCore, как и другие модели & modelItems являются.

QStandardItem использует - и, следовательно, имеет зависимость от - нескольких типов QtGui, таких как QIcon и QBrush, следовательно, он должен быть частью QtGui.

Итак, как я уже сказал, я понимаю ваше разочарование, но, в интересах остатка довольно общего кода Qt в его нынешнем виде, на самом деле очень удобно.