Comments 20
Можно запихнуть код в тег
?
Интересно, с вашими 15-ю проксями не тормозит?
Ну пока не замечал, хотя с большими наборами данных не тестил, да а с чего им тормозить. Все 15 проксей они не последовательно одна за другой. У меня из них древовидная иерархия. Т.е. есть одна исходная модель данных и скажем 4 представления. Между исходной моделью и каждым представлением 1-3 прокси. А так как они связаны между собой мехнизмом сигналов-слотов, который если верить докам очень быстрый.
Что такое O(0)? Наверное, вы имели ввиду O(1) — константа по отношению к количеству элементов в исходной модели.
Думаю, нужно рассмотреть три параметра: n — количество элементов в исходной модели, k — количество проксей на пути к вью, l — количество элементов, отображаемых во вью. Количество действий для отображение при правильно спроектированных прокси должно вести себя как O(k*l), т.е не расти с ростом n. Т.к l — число маленькое (обычно не более 30), то с каждой новой прокси будет добавляться незначительное для задач GUI количество операций.
Думаю, нужно рассмотреть три параметра: n — количество элементов в исходной модели, k — количество проксей на пути к вью, l — количество элементов, отображаемых во вью. Количество действий для отображение при правильно спроектированных прокси должно вести себя как O(k*l), т.е не расти с ростом n. Т.к l — число маленькое (обычно не более 30), то с каждой новой прокси будет добавляться незначительное для задач GUI количество операций.
Оффтопик, конечно, но мне очень интересна реализация вот какой штуки: у QTreeView нет такой фичи как band selection (из QTreeView можно сделать report list, если возникнет вопрос «зачем это надо?»). Как правильно реализовать band selection? Может быть подскажете готовую реализацию? Или общее направление для изучения? (В менеджере KDE Dolphin сделано то, что надо, но, честно сказать, мне сложно разобраться что за что отвечает)
Если честно, не очень понял вопрос… Слишком размыто… Понял только что из QtreeView нужно выбирать диапазон айтемов, а что с ним делать…
Я про выделение мышкой диапазона элементов (или диапазонов в комбинациях с кнопками Ctrl или Shift), с отображением области (прямоугольной) выделения.
Стандартное поведение для report list в Windows (вот этот затемнённый прямоугольник вроде называется rubber-band, а действие по выделению items таким способом band selection, но я могу сильно ошибаться, не силён в терминологии).
Стандартное поведение для report list в Windows (вот этот затемнённый прямоугольник вроде называется rubber-band, а действие по выделению items таким способом band selection, но я могу сильно ошибаться, не силён в терминологии).
Ох и эуйня.
Очень интересная тема.
Если не секрет, скажите, какие ещё типы прокси кроме Union используете?
Если не секрет, скажите, какие ещё типы прокси кроме Union используете?
Не секрет. Еще UngroupProxy (TreeModel(2 уровня) -> ListModel (дети из TreeMode))
Планирую GroupProxy (ListModel->TreeModel) группировать элементы списка по набору предустановленных групп.
Планирую GroupProxy (ListModel->TreeModel) группировать элементы списка по набору предустановленных групп.
GroupProxy будет требовать сортировки? Я не изучал этот вопрос, но как в Qt решается вопрос сортировки, ведь время на неё существенно зависит от размера исходной модели? Сортировать GUI-потоком точно нельзя.
В исходниках QSortFilterProxy никаких упоминаний про потоки не нашел, поэтому при больших объемах сортируемых данных гуй наверно будет виснуть. Так что стандартными средствами мне кажеться только такой вариант есть. А с потоками это самому нужно писать думаю…
Да, тоже пришлось качнуть исходники и посмотреть QSortFilterProxyModel. Сделано достаточно наивно — сортируется синхронно прямо внутри QSortFilterProxyModel::sort.
Меня как раз интересуют Qt-шные модели для больших объёмов данных (несколько миллионов). Тут однозначно будет подвисание. Для сортировки дополнительным потоком, да, придётся писать свою AsyncSortProxyModel.
Думаю, она вполне может работать так: считывать данные из нижлежащей модели последовательно блоками, сортировать считанный блок, затем слиянием добавлять элементы из нового отсортированного блока к множеству уже отсорированных элементов и нотифицировать GUI. Для пользователя это будет выглядеть так: после того как он инициировал сортировку, элементов в таблице становится мало и их количество постоянно растёт не замораживая GUI. Он сможет промотать скролл к концу таблицы, после этого появятся новые элементы и скролл отодвинется от конца.
Меня как раз интересуют Qt-шные модели для больших объёмов данных (несколько миллионов). Тут однозначно будет подвисание. Для сортировки дополнительным потоком, да, придётся писать свою AsyncSortProxyModel.
Думаю, она вполне может работать так: считывать данные из нижлежащей модели последовательно блоками, сортировать считанный блок, затем слиянием добавлять элементы из нового отсортированного блока к множеству уже отсорированных элементов и нотифицировать GUI. Для пользователя это будет выглядеть так: после того как он инициировал сортировку, элементов в таблице становится мало и их количество постоянно растёт не замораживая GUI. Он сможет промотать скролл к концу таблицы, после этого появятся новые элементы и скролл отодвинется от конца.
Думаю да. Почему GUI потоком нельзя, зачем тогда QSortFilterProxyModel::sort (..)
Спасибо, вы направили меня на верный путь.
Sign up to leave a comment.
Трюки с моделями в Qt