Полосы прокрутки для большого объема данных

У QAbstractItemModel есть методы canFetchMore и fetchMore. При достижении низа при прокрутке можно подгружать новые данные, например.

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

Голосую за разбитие на страницы (табы). Самое разумное решение.

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

Ну и еще это не QAbstractItemModel, а наследник от QAbstractScrollArea, но это не так важно.

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

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

Разбить не получается, у данных нет логических границ.

Ну сделай два скроллбара. Один будет перемещать твоё «окно» длиной 10к строк по всему файлу, а второй будет осуществлять прокрутку в этом «окне». Хотя получится фигня какая-то.

Разбить не получается, у данных нет логических границ.

Страница будет просто вмещать N очередных строк. Тут не надо никакой логической разбивки.

Вообще тупо скролл по миллиону строк нафиг никому не нужен, потому как заколебешься позиционировать на нужные данные. Часто такие объемы данных скроллят уже после какой-либо фильтрации.

Посмотри на реализацию прокрутки и навигации в плеерах (vlc, smplayer).

Страница будет просто вмещать N очередных строк. Тут не надо никакой логической разбивки.

Не пойдет. Данные выводятся для анализа людьми, люди хотят видеть слитные данные.

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

Задача абсолютного положения внутри миллионов строк от полос прокрутки не требуется.

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

Как вариант: сделай скролл скроллером мыши.

как вариант:
1. запретить скроллбар справа
2. нарисовать его снизу (как в плеерах)
3. тамже поле ввода вручную строки
4. кнопка на 1 строку вниз (хоткей стрелка вниз)
5. кнопка на 1 строку вверх (хоткей стрелка вверх)
6. кнопка на 1 страницу вверх (хоткей pgup)
7. кнопка на 1 страницу вниз (хоткей pgdn)
8. кнопка на 1% строк вниз (хоткей стрелка вправо)
9. кнопка на 1% строк вверх (хоткей стрелка влево)

Тогда давай подробнее, что за данные, которые должны быть слитные и которых миллион строк и которые должен видеть человек

Самая простая аналогия - бинарный редактор на /dev/mem. Полный объем документа может измеряться гигабайтами. Переход в нужный адрес - по команде извне. Но как только оказались в нужном месте - необходима возможность непрерывной прокрутки. Ну и если хочется, то крути хоть все гигабайты.

Режим работы - посмотрели что-то, из просмотренного узнали новое положение, перешли туда, опять смотрим.

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

Режим работы - посмотрели что-то, из просмотренного узнали новое положение, перешли туда, опять смотрим.

Закладочки можно сделать по ctrl-123.

Фильтр (окно) само должно двигаться при подходе к границам.

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

И не только ощущаются, но и реализовываются с костылями, что намекает на то, что я делаю что-то не так.

У QScrollBar сигнал valueChanged() вызывается даже при ручной установке нового положения. Но новое положение нужно устанавливать в valueChanged() при достижении пределов. Полной рекурсии не получается из-за того как организованы сигналы, но выглядит криво все-равно.

есть такой костыль:

1. заблокировал/отключил сигнал

2. передвинул скролл

3. разблокировал/включил сигнал

А вообще по твоему описанию пойдет такое:

1. скроллбар не трогай 2. скролл мышой (ее скроллером) на поле виджета (возможно, с нажатым ctrl) и клавишами вверх-вниз 3. переход на нужную строку по введенному значению (типа поиск) или номеру строки 4. Как уже писали выше - обязательны закладки и переход к предыдущим положениям в списке

Можно сделать свой компонент, который будет сам грузить и подтирать ненужные строки. У QTableWidget есть свойства которые говорят об области видимости - вот на базе него. Но чтобы добиться плавности прокрутки наверное придется как-то потрудиться дополнительно...

есть такой костыль:

Замечательно. Костыль помог. Сделал для теста следующее:

1. Диапазон ScrollBar-а 0-10000 (окно). Смещение окна = 0.

2. При достижении 10000 положение устанавливается в 9000 и к смещению прибавляется 1000.

3. При достижении 0, положение устанавливается в 1000 и от смещения отнимается 1000.

4. При отрисовке запрашиваются данные по смещение + положение ScrollBar-а.

Таким образом ScrollBar всегда имеет диапазон 0-10000 и не нужно бороться с ограничениями на максимальное положение (signed int).

С реальными данными не проверял, но на тестовых пустышках все выглядит хорошо и ощущается естественно и приятно.

В добавок ко всему, быстрая прокрутка осуществляется захватом ползунка, удавливанием его вниз и возней мышкой вправо и влево.

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