Ожидание сигнала

[Авварон]

Посмотрите как QFileSystemModel работает, она грузит астнхронно

[Old]

Ну если "асинхронно", то надо полагать что RestEventLoop выполняется в др нитке (не главной).

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

[Azazello]

Посмотрите как QFileSystemModel работает, она грузит астнхронно

Спасибо, но не поможет. Он грузит все данные без подкачки

[Igors]

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

Вот как работает мой старенький LLDB отладчик. Жму на треугольник expand/collapse чтобы увидеть члены структуры. Tреугольник реагирует (поворачивается), но никаких новых (child) айтемов (пока) нету. UI полностью свободно, можно ресайзить и.т.п. - все что угодно. Ну ладно, закурил, налил чайку и, всего лишь через минуту.. вот они, члены структуры, появились! Ну конечно так не всякий раз, но частенько.

Да, минусы очевидны "я нажал, а оно..". Однако если (как Вы утверждаете) момент приема данных неизвестен, то другого корректного решения нет.  Асинхронно - значит асинхронно, и нечего крутить лупы и замораживать UI чтобы из нее сделать синхронку.

Вывод: Дизайн MVC (в Qt) не предназначен для асинхронной загрузки данных.

Да, не получается - значит Qt виновато (ну а кто же еще?) 

[Azazello]

Да, не получается - значит Qt виновато (ну а кто же еще?)  

Ну поговорим . Начнем с того, что я не говорил, что у меня не получается, а говорил, что коробочный вариант Qt MVC не предусматривает асинхронную загрузку.

А с другой стороны, сколько, сколько раз (я не знаю, предполагаю) вы давали здесь советы - у вас неверная архитектура, пересмотрите её? Даже ваш последние топики посвещены переделу архитектуры.

Тогда получается, все, кто говорит про архитектуру изначально не прав. Ибо лукавит. Когда говорим про свою архитектуру - она может быть не правильна. Но Qt создавали боги, поэтому такое рассуждение кощунство. Или это из области -   дай мудрости не перепутать одно с другим? Но вопрос то стоит в другом - Qt:не трогай архитектуру, у тебя руки кривые. Свой проект - переделай архитектуру, у тебя руки кривые.

[Igors]

... Qt:не трогай архитектуру, у тебя руки кривые. Свой проект - переделай архитектуру, у тебя руки кривые.

Согласен, когда "слон слишком велик" - на него не лают. Хотя то же самое "в велосипедном исполнении" будет охаяно немедленно. Такова человеческая природа, ничего не попишешь  Однако все-таки вернемся к теме.

..я не говорил, что у меня не получается, а говорил, что коробочный вариант Qt MVC не предусматривает асинхронную загрузку.

Хмм... не понял, а что в данном конкретном случае он должен "предусматривать"? Какого чуда Вы ожидали "ис каропки"? Юзер давит бубочку  "expand" - UI должно ему "ответить ответ". Если "достаточно быстрый" ответ невозможен - надо отпускать UI, т.е. выходить в событийный цикл, и показать юзеру что, мол, "процесс пошел". А потом, когда данные придут, по событию уже вставить строки.

А Вы что? Из обработчика одного события зовете др события - верный способ нарваться на неприятности, и Вам это прекрасно известно. Так что все верно - у Вас "архитектура кривая" 

[Azazello]

Хмм... не понял, а что в данном конкретном случае он должен "предусматривать"? Какого чуда Вы ожидали "ис каропки"? Юзер давит бубочку  "expand" - UI должно ему "ответить ответ". Если "достаточно быстрый" ответ невозможен - надо отпускать UI, т.е. выходить в событийный цикл, и показать юзеру что, мол, "процесс пошел". А потом, когда данные придут, по событию уже вставить строки.

А Вы что? Из обработчика одного события зовете др события - верный способ нарваться на неприятности, и Вам это прекрасно известно. Так что все верно - у Вас "архитектура кривая"  

Давайте приведу пример конктетный. Будем брать для упрощения таблицу, а не дерево.

Итак, используется асинхронная модель с вью.
Вы смотрите данные и листаете их. Доходите до конца.
В случае синхронной модели: Пошел запрос, гуи ждет данные, появились, .отобразились.
В случае асинхонной модели: Пошел запрос. Данных ещё нет. А вы то листаете все равно -т.е. посылаете запросы. Пошел запрос, данных ещё нет. А вы все листаете. А вью смотрит не на те данные которые будут, а на банальный rowCount. И в определенный момент у вас появится не один пакет данных, а несколько, сколько вы там мышкой накляцали до 1-го прихода данных.

Конечно, в вашем дереве это не будет происходить, т.к. скорее вся ветка закачивается один раз и запрашивается только один раз.

Другой пример: resizeEvent. Как не создавай виджет, а два ресайза будет, и он 2 раза скажет fetchMore, потому что после первого fetchMore данные банально не успеют загрузится. Итог - два пакета данных при старте. Критично? Ну кому как. У меня сервер Rest считает эти запросы и каждый запрос имеет свою цену, причем не виртуальную, а которая считается.

Понятно, можно придумать много решений - все свои вью к примеру, которые смотрят на количество запрашиваемых данных.
А можно при запросе создавать "пустые" данные, которые будут заменятся на рабочие. Но это все так усложняет..... Это надо помечать что они пустые, чтобы не использовать их. А если их скачалось меньше чем ожидалось, удалять. ........ А в случае со сценой эти данные нужно куда то добавить, чтобы они были в сцене, но не отображались и не участвовали во всяких вычислениях..... А если рест сервер медленный или загнулся, то можно столько накляцать пустых данных, что мало не покажется. Тогда нужно ставить ограничения и пошло поехало........

[Авварон]

Лол, потому и нужна очередь.
Пришёл фетчмор - смотрим, мы уже запрашивали этот кусок? Нет, запрашиваем и кладём в очередь идентификатор индекса (в терминах ФС имя папки).
Папка прогрузилась, вставляем строки, убираем путь из очереди.
Боде, ну откройте код qfilesystemmode уже

[Azazello]

Лол, потому и нужна очередь.
Пришёл фетчмор - смотрим, мы уже запрашивали этот кусок? Нет, запрашиваем и кладём в очередь идентификатор индекса (в терминах ФС имя папки).
Папка прогрузилась, вставляем строки, убираем путь из очереди.
Боде, ну откройте код qfilesystemmode уже

Так. Давайте закроем тему. А то меня не понимают, видно не стоит расширять вопросы, должны быть конкретные и не охватывать большУю область.
Блин. Еще раз повторюсь, qfilesystemmodel не делает подкачку данных, она их сразу ВСЕ скачивает. Да, он делает запрос на закачку ноды дерева, но ВСЕЙ ноды.
Я же вам говорю про другую подчкачку данных - в пределах таблицы, или в пределах одной ноды дерева. Как в QtSQL. Если база данных поддерживает курсор, SqlModel скачает первые 256 записей. Когда вы наступите на 256-ю, он закачает следущие 256. Где там в qfilesystemmodel - скачать следующие файлы/папки по списку. Не,там запрос на все файлы в папке.

Мой пример: вы открыли youtube и ведете скрол вниз, у вас подтягиваются данные.
Ваш пример: вы открыли youtube и кляцнули на категорию, и у вас тоже подтягиваются данные.

Но есть нюанс
https://pikabu.ru/story/anekdot_pro_nyuans__349792

[Авварон]

Как делать заначку не всей годы разобрано в примере fetchMore, если мне память не изменчет

[Azazello]

Как делать заначку не всей годы разобрано в примере fetchMore, если мне память не изменчет

Я так понял, вы сделали заначку. На все годы.... А потом память изменила и заначка пропала )))))))))

[Igors]

В случае синхронной модели:
В случае асинхонной модели:

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

Пошел запрос. Данных ещё нет. А вы то листаете все равно -т.е. посылаете запросы. Пошел запрос, данных ещё нет. А вы все листаете. А вью смотрит не на те данные которые будут, а на банальный rowCount. И в определенный момент у вас появится не один пакет данных, а несколько, сколько вы там мышкой накляцали до 1-го прихода данных.

Что здесь значит "листаете"? Если данных еще нет - как (или что) я могу листать? Видимо об этом Вы упоминаете дальше

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

Думаю это неудачная затея, такие пустышки станут "источником постоянных забот", лучше обойтись без них, сценарий Вы же и рассказали

Я же вам говорю про другую подчкачку данных - в пределах таблицы, или в пределах одной ноды дерева. Как в QtSQL. Если база данных поддерживает курсор, SqlModel скачает первые 256 записей. Когда вы наступите на 256-ю, он закачает следущие 256.

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