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