Comments 13
У вас были какие-то проблемы с производительностью, что понадобилось кэширование?
Если меняется так много данных, может стоит использовать beginResetModel()?
Если меняется так много данных, может стоит использовать beginResetModel()?
Такая схема мне понадобилась потому что мои данные часто обновляются извне (не через View) и моя структура не может отправлять данные об изменении (она не знает об QAbstractItemModel и индексах). А beginResetModel() не может быть мне другом — мне нужно, чтобы все выделенные и раскрытые узлы модели вместе с полосами прокрутки остались на месте. Данные у меня меняются зачастую немного, но иногда очень значительно и хочется, чтобы для небольших изменений программа была дружелюбна к пользователю.
Помимо этого удобство этого адаптера заключается в том, что при его использовании не нужно тянуть никакую логику по обновлению древовидной модели через beginInsertRows/endInsertRows, beginRemoveRows/endRemoveRows рискуя потратить кучу времени на отладку — теперь вместо этого можно сделать beginUpdate() / endUpdate() и всё это сделается автоматом без лишней головной боли и с минимальным оверхедом
На самом деле обработка сигналов roswInserted/RowsDeleted не то чтобы дорогая во view, потому что view не начинает все перерисовывать, а откладывает обновление на некоторый промежуток времени, так что если идет большой поток изменений, то перерисовано окно будет всего один раз. Так что я не уверен, что такой подход даст большой выигрыш в производительности, если вообще даст.
Но вообще подход имеет место, в случае если таким образом удобно делать мост с «настоящей» моделью, хотя предпочтительнее все же заставить вашу структуру смочь отправлять данные об изменении, пусть она и не знает при этом ничего об индексах.
Но вообще подход имеет место, в случае если таким образом удобно делать мост с «настоящей» моделью, хотя предпочтительнее все же заставить вашу структуру смочь отправлять данные об изменении, пусть она и не знает при этом ничего об индексах.
Согласен, но иногда эти изменения могут иметь значения, если обновлений достаточно много, т.к. rowsInserted/RowsDeleted каждый раз обновляют весь список QPersistenIndex-ов на модель. И если у меня будет десяток тысяч обновлений внутри скрытого узла, то это добавит лишнюю, хоть и незначительную задержку (у меня так происходит во время работы пользовательских скриптов). В моем же случае если все эти изменения происходят внутри скрытого узла — то модель не получит ни единого обновления.
зато если пользователь предварительно хотя бы раз развернет все узлы, то ваш подход, как я понял, будет серьезно тормозить. А количество QPersistenIndex-ов не велико обычно — только выделение же. Обычно это 1 индекс, если можно выделять несколько — то с десяток. Редко больше.
если в дереве мало изменений, то синхронизация отработает быстро даже для сравнительно большого дерева, ну а если изменений много, то тут уж ничего не поделаешь
количество выделенных элементов (а следовательно QPersistentIndex-ов) у меня может быть очень значительно — сотня-другая элементов запросто, а то и под тысячу. Я нас конструкторская программа и пользователь может на 3d модели выделять для редактирования значительное количество элементов и выделенные элементы должны быть выделенными и в дереве
не туда
Когда переключаешься на Qt с, например .NET и WPF, то модели вызывают, наверное, больше всего вопросов. Вот есть у нас объекты с данными и есть контролы которые их отображают. Необходимость каждый раз создавать еще и специального посредника между ними — раздражает. Подход когда данные реализуют интерфейсы для уведомления о своем изменении (типа INotifyPropertyChanged и INotifyCollectionChanged), а контрол посредством биндингов привязывается напрямую к свойствам объектов данных кажется более удачным.
Sign up to leave a comment.
Обновление древовидной модели в Qt