HowTo: Модель для неупорядоченных данных

[ритт]

умора нет, я должен был бросить всё и расжёвывать всё до полного понимания?)
ой, как было бы хорошо с контроллером...ну, нет контроллера, контроллера нет. так что же теперь? "босс, мы все умрём! даже ты, босс!"

Ммм... Я правильно понял, что основную негативную реакцию вызвали мои «лирические отступления», в которых я сетую на несовершенство реализации MVC в Qt?

нет. я в среднем в месяц нахожу по баге-две и давно бросил их считать - одни банальны и легко исправляются, иные могут потребовать изменения интерфейса и до начала работ над 5.0 о них даже сообщать бессмысленно. из-за некоторых из них пару занимательных проектов мне пришлось приостановить как минимум до смены модели контрибуций. но по теории ошибки это всё неизбежно. я сообщаю о проблемах, пишу патчи - посильно пытаюсь улучшить инструмент. и все эти неудобства, с которыми мне пришлось столкнуться за время работы с Qt, даже не побудили меня отказаться от неё в пользу какого-нибудь точканета или жавы (или, тьфу-тьфу, гтк).
для тебя, внимательный читатель, это всего лишь букавки а для меня это показатель. да хотя бы просто сравнить Qt3 с Qt4...

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

хотя, с другой стороны,

Про то, что можно было бы (если бы да кабы...) с этим сделать я уже отписал в письме Константину.

я заглянул в ПМ, заглянул в почту - письма от тебя не нашёл ни здесь, ни там. если отправлял что-то мне на мыльник, то я или напрочь этого не помню, или не получал.

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

вернулся к оригинальному треду и нашёл единственный сниппет, который я выкладывал:

Код:

void MyModel::insertMyRow(const QString& key, const MyData& data)
{
    beginInsertRows(...);

    m_sourceHash[key] = data;

    endInsertRows(...);
}

(http://www.prog.org.ru/index.php?topic=7622.msg53001#msg53001)
право же, у меня фантазии не хватает понять как из этого...ммм...кода были сделаны выводы...которые были сделаны)

[Eugene Efremov]

Ммм... Я правильно понял, что основную негативную реакцию вызвали мои «лирические отступления», в которых я сетую на несовершенство реализации MVC в Qt?

нет. я в среднем в месяц нахожу по баге-две и давно бросил их считать - одни банальны и легко исправляются, иные могут потребовать изменения интерфейса и до начала работ над 5.0 о них даже сообщать бессмысленно. из-за некоторых из них пару занимательных проектов мне пришлось приостановить как минимум до смены модели контрибуций. но по теории ошибки это всё неизбежно. я сообщаю о проблемах, пишу патчи - посильно пытаюсь улучшить инструмент. и все эти неудобства, с которыми мне пришлось столкнуться за время работы с Qt, даже не побудили меня отказаться от неё в пользу какого-нибудь точканета или жавы

Не понял, к чему это все?
Да, из существующих на сегодня инструментов Qt — лучше, что мы имеем. И что?

Код:

void MyModel::insertMyRow(const QString& key, const MyData& data)
{
    beginInsertRows(...);

    m_sourceHash[key] = data;

    endInsertRows(...);
}

(http://www.prog.org.ru/index.php?topic=7622.msg53001#msg53001)
право же, у меня фантазии не хватает понять как из этого...ммм...кода были сделаны выводы...которые были сделаны)

Выводы были сделаны очень простые:
1. beginInsertRows/endInsertRows можно и нужно использовать за пределами insertRows — при реализации собственных методов вставки данных.
2. Поскольку в этом фрагменте мы вставляем данные в хэш — мы не можем контролировать, куда именно они вставятся. Следовательно, если этот код верен, то мы можем вставлять данные куда заходим, а не только в тот диапазон, который мы задали в beginInsertRows.

Последний вывод меня сильно удивил. И я специально тебя переспросил по этому поводу — так ли это и не надо нам в этом случае делать что-то еще? Ответа на свой вопрос я не получил (кстати, я не получил его и сейчас).

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

Про то, что можно было бы (если бы да кабы...) с этим сделать я уже отписал в письме Константину.

я заглянул в ПМ, заглянул в почту - письма от тебя не нашёл ни здесь, ни там. если отправлял что-то мне на мыльник, то я или напрочь этого не помню, или не получал.

Какой e-mail, какое ПМ?
Письмо в этом треде имеется в виду. Вот это.

Знаешь, чем больше я с тобой переписываюсь, тем больше у меня складывается впечатление, что мы говорим на разных языках. И понимаем друг друга хорошо если наполовину.
Постоянно выясняется, что под одними и теми же словами мы имеем в виду совершенно разные вещи. И делаем из этих слов совершенно не те выводы, на которые рассчитывал собеседник. Что с этим делать, я не знаю. Но, по крайней мере, нужно учитывать, что наиболее вероятной причиной любых возможных разногласий скорее всего является элементарное взаимонепонимание.

[Eugene Efremov]

Где? Никакой вставки произвольного числа строк за раз у меня нет. Кроме, конечно, требуемого интерфейсом insertRows.

Дык кто ж мешает, если count > 1 просто возвращать false? Зачем "натягивать" вставку многих записей, если это совершенно не нужно для нашей модели? Именно такое поведение у QSQLTableModel при некоторых настройках...

Можно конечно. Но мне не кажется, что это сколько-нибудь существенно повлияет на всю эту систему...

Возможно, было бы полезно сделать некий наследник QAbstractTableModel, который бы поддерживал понятие "текущая редактируемая строка".

Угу, вот только у нас, помимо QAbstractTableModel, есть уже готовый ворох ее наследников. И если мы хотим дополнить ее интерфейс для всех случаев — встает проблема, что делать с ними со всеми...

Ну на самом деле ни такой уж и ворох - QAbstractListModel (для которой это малоактуально), QAbstractTableModel и QStandartItemModel. Если неохота писать двух наследников - можно извернуться с шаблонным классом, предок которого определяется аргументом шаблона

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

Так что, если такие правки делать (а там, в принципе, еще много чего можно добавить), то лучше, IMHO, под конкретную модель конкретного проекта, которая уже сама должна встать в корне иерархии моделей этого проекта.

[ритт]

Какой e-mail, какое ПМ? Письмо в этом треде имеется в виду. Вот это.

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

Выводы были сделаны очень простые:
1. beginInsertRows/endInsertRows можно и нужно использовать за пределами insertRows — при реализации собственных методов вставки данных.
2. Поскольку в этом фрагменте мы вставляем данные в хэш — мы не можем контролировать, куда именно они вставятся. Следовательно, если этот код верен, то мы можем вставлять данные куда заходим, а не только в тот диапазон, который мы задали в beginInsertRows.

неверные выводы. если я ввёл в заблуждение фразой "я использую такую-то конструкцию для заполнения модели из кэша", ну, прости. опять же непонимание диалектов. я не вижу здесь "четкого и ясного" пояснения, что, мол, один хрен куда вставлять данные. в бэкинсторе может и один хрен, а подписчикам нужно сигналить правильно, если хочешь правильной работы.
если помнишь, я предлагал написать простенькую item-based модель и работать с ней.

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

[ритт]

кстати, вот:

void QAbstractItemModel::rowsInserted ( const QModelIndex & parent, int start, int end )   [signal]

This signal is emitted after rows have been inserted into the model. The new items are those between start and end inclusive, under the given parent item.

Note: Components connected to this signal use it to adapt to changes in the model's dimensions. It can only be emitted by the QAbstractItemModel implementation, and cannot be explicitly emitted in subclass code.

See also insertRows() and beginInsertRows().

чётко и ясно - есть старт, есть энд для определённого парента

[xintrea]

С интересом почитал тред. Узнал, что в Qt недовольны реализацией MVC.

Каг считают гуру, означает ли это что в Qt 5.0 логика MVC в Qt будет переработана?

[ритт]

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

[pastor]

Каг считают гуру, означает ли это что в Qt 5.0 логика MVC в Qt будет переработана?

Очень даже возможно

[Eugene Efremov]

Какой e-mail, какое ПМ? Письмо в этом треде имеется в виду. Вот это.

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

О том и речь. Для меня сообщение в треде на форуме — тоже вполне себе письмо...

И раз у нас возможны такие непонятки — предлагаю сосредоточиться в первую очередь на исходном коде. Уж на C++, в отличии от русского языка, неоднозначная трактовка маловероятна...

2. Поскольку в этом фрагменте мы вставляем данные в хэш — мы не можем контролировать, куда именно они вставятся. Следовательно, если этот код верен, то мы можем вставлять данные куда заходим, а не только в тот диапазон, который мы задали в beginInsertRows.

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

Но тогда, опять-таки, встает вопрос, что делать в описанной ситуации. Вот у нас данные, мы их хотим вставить в хэш. Что нам передавать beginInsertRows?

Сейчас туда пишется нечто мало осмысленное. Можно, конечно, сперва вставить пустые строки в конец модели, а потом вызвать insertToEmpty. А insertToHash вообще выкинуть. Но уж больно криво получается...

если помнишь, я предлагал написать простенькую item-based модель и работать с ней.

Угу. И именно это я и попытался сделать. Получилось... то что получилось.

И собственно, именно на этом коде я и предлагаю сосредоточиться.
Какие ошибки ты видишь в нём?
Одну ошибку уже и сам могу назвать — это то самое неправильное использование beginInsertRows. Но способа ее исправить я пока не вижу.

/* Код находится в приложении к первому сообщению в теме. Пока что, оно скачано 0 раз. */

а, ещё - индексы не используются для хранения данных, индексы указывают на данныне. не прямо-таки указывают "данные здесь", а позволяют оперировать с данными по некому указанию позиции в модели.

Похоже — опять разница в языках. Для меня «указывают на» и «хранят указатель/ссылку/etc на» по смыслу суть синонимы...

И речь в том отступлении шла о том, в качестве такой ссылки можно было бы использовать ключ от хэша, но реализация этого не позволяет, а потому мы этот механизм не используем. (И, кстати, целью оного отступления было именно объяснить, почему этот механизм в модели не используется. А вовсе не «наезды на троллей» или что-то еще в таком духе.)

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

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

[ритт]

Но тогда, опять-таки, встает вопрос, что делать в описанной ситуации. Вот у нас данные, мы их хотим вставить в хэш. Что нам передавать beginInsertRows?

Сейчас туда пишется нечто мало осмысленное. Можно, конечно, сперва вставить пустые строки в конец модели, а потом вызвать insertToEmpty. А insertToHash вообще выкинуть. Но уж больно криво получается...

не нужно никаких пустых строк. чего ты к ним привязался? )
добавь метод, принимающий список...чего там у тебя? строки? в общем, список "строк", где каждая "строка" - данные для строки модели. зови beginInsertRows(...) для вставки нужного количества строк, например, в конец списка (неважно куда - важно соблюдать заданную последовательность). между beginInsertRows(...)/endInsertRows() вставляй свои строки в хэш. для соблюдения последовательности тебе нужно завести вектор индексов и растягивать/сжимать его при добавлении/удалении строк. здесь ограничение - такая модель сможет работать только с уникальным набором ключей (что тебе, собственно, и требовалось). вопросы?

[Eugene Efremov]

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

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

Для ускорения доступа мы могли бы сохранять ключи в отдельном массиве и обращаться к его индексам. И в реальности, скорее всего, так бы и поступили. Но это лишило бы ценности наш пример, поскольку данные перестали бы быть неупорядоченными.

Однако, судя по всему, именно так и придется сделать. Альтернативы слишком уж кривыми получаются.

вопросы?

Вопрос один, и чисто риторический.
Как же с этим справляются модели, работающие с файловыми системами, базами данных и т.д.? Они что, тоже заводят промежуточные массивы для сохранения порядка индексов?

(посмотрев код QFileSystemModel) Мда. Похоже, именно это они и делают. Все, больше вопросов нет. Видно, придется переписывать все заново под этот вариант...

[ритт]

с этим всё просто - во вьюхе данные отображаются в определённом порядке или как-попало? если бы "как-попало", модели были бы не нужны )