beginRemoveRows не понятно как работает

[spectre71]

Делаю:

Код

C++ (Qt)
QObject::connect(ProjectView->selectionModel(), SIGNAL(currentRowChanged (const QModelIndex &, const QModelIndex &)), ProjectModel, SLOT(onCurrentChanged (const QModelIndex &, const QModelIndex &)));
 
void TProjectModel::onCurrentChanged (const QModelIndex & current, const QModelIndex & previous) {
  if(!Project)            {return;}
  if(!current.isValid())  {itemIndex(-1);}
  itemIndex(current.row());
}
 

Какого фига при вызове beginRemoveRows у меня вызывается onCurrentChanged и соответственно меняется itemIndex(current.row());
Логично что это должно происходить на endRemoveRows

[Rcus]

beginRemoveRows оповещает представления об удалении данных, чтобы те больше не ссылались на них, отменили редактирование. Потом пересчитываются индексы(если точнее то в begin происходит инвалидация, в end процедура перерасчета). А endRemoveRows оповещает об окончании изменений. (RTFS)

[spectre71]

beginRemoveRows оповещает представления об удалении данных, чтобы те больше не ссылались на них, отменили редактирование. Потом пересчитываются индексы(если точнее то в begin происходит инвалидация, в end процедура перерасчета). А endRemoveRows оповещает об окончании изменений. (RTFS)

Что значит инвалидация?
Логично когда на "begin..." делаются оповещения и блокировки, а на "end..." изменения и разблокировки.
Здесь же какой-то бред.

[Rcus]

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

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

[ритт]

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

Spectre, всё правильно - так и должно быть.

[spectre71]

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

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

С чего оно провокационное?
Если вы хотите сказать что QT настолько круто, что там нет концептуальных ошибок, то вы не правы.
Насчет эволюции вы правы, она есть, но то что на данной стадии все хорошо, я не согласен.

[spectre71]

Spectre, всё правильно - так и должно быть.

Просто концептуальная ошибка. Скорее всего дело в том что QItemSelectionModel реально на уровне "View", а не "Model".

[Rcus]

С чего оно провокационное?
Если вы хотите сказать что QT настолько круто, что там нет концептуальных ошибок, то вы не правы.
Насчет эволюции вы правы, она есть, но то что на данной стадии все хорошо, я не согласен.

В том то и дело, что оно провоцирует искать аргументы в защиту архитектуры Qt, что обычно выливается в страницы флейма /*\see Qt vs .NET*/ а не обсуждать решения интересных задач возникающих при работе.
Хотя конечно Qt не идеальная библиотека, просто остальные еще хуже (Это уже провокация любителей gtk, wx, mfc, wpf с моей стороны)

[spectre71]

В том то и дело, что оно провоцирует искать аргументы в защиту архитектуры Qt, что обычно выливается в страницы флейма /*\see Qt vs .NET*/ а не обсуждать решения интересных задач возникающих при работе.
Хотя конечно Qt не идеальная библиотека, просто остальные еще хуже (Это уже провокация любителей gtk, wx, mfc, wpf с моей стороны)

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

[BRE]

А защищать слабые места архитектуры не надо. Надо пытаться их понять и искать способы обойти и/или если есть возможность влиять на ее дальнейшее развитие.

А на столько ли ты понял архитектуру MVC в реализации Qt, что считаешь ее слабой? 
Может сначало нужно хорошенько с ней разобраться и возможно такие мысли уйдут сами собой?

Пока это выглядит как: "Я ожидал вот это, но это работает не так как я ожидал, значит это концептуальная ошибка!" 

Просто концептуальная ошибка. Скорее всего дело в том что QItemSelectionModel реально на уровне "View", а не "Model".

А QItemSelectionModel и должна находиться на уровне View.
Источник данных не должна запоминать, что выбрал пользователь, он просто должна вернуть данные по запросу.

[spectre71]

А на столько ли ты понял архитектуру MVC в реализации Qt, что считаешь ее слабой? 
Может сначало нужно хорошенько с ней разобраться и возможно такие мысли уйдут сами собой?

Пока это выглядит как: "Я ожидал вот это, но это работает не так как я ожидал, значит это концептуальная ошибка!" 

А на столько ли ты понял архитектуру MVC в реализации Qt что можешь привести мне выдержки из документации и указать на мою ошибку?
И по поводу MVC, ее как таковой в QT нет, есть только MV.

А QItemSelectionModel и должна находиться на уровне View.
Источник данных не должна запоминать, что выбрал пользователь, он просто должна вернуть данные по запросу.

А это весьма сомнительное утверждение. Все зависит от источника данных и текущего его использования.
В большенстве моих списочных данных, есть понятие выбранный элемент, который должен поддерживаться актуальным, если список не пуст и не должен просто так прыгать туда-сюда, как это получилось с beginRemoveRows.
Именно данные у меня определяют выбранный элемент, а не View. View может только так или иначе отображать и обеспечевать возможность изменения выборанного элемента. А в текущей MV концепции получается большой геморой с синхронизацией селекции между представлением и данными. Уже начальная установка селекции не обеспечивается уровнем модели, устанавливая модель во View приходиться еще и устанавливать правильно селекцию, а модель про селекцию ничего не знает! Тоже самое происходит при перемещениях элементов списка их удаления, добавления: заново приходиться переустанавливать селекцию, при этом блокируя обратную связь селекции с моделью.

Привиду пример того что у меня происходит при изменении выбранного элемента в одном из списков данных "Project".
"Project" - граф узлами которого являются задачи, а ребра связи между задачами(передача данных от одних задач к другим).
"Project" - имеет 2 визуальных представления:
- список задач в QTableView
- граф в Pipeline Editor
Выбрать текущую можно как в одном так и в другом представлении и это должно быть синхронизировано!
При изменении выбранной(текущей) задачи происходит переустановка данных в массе компонентов:
- Property Editor (свойства задачи)
- Console (может потребовать закрытия, открытия и прочтения определенных файлов)
- Таблиц со списками результатов
- Вспомогательных компонентов типа редактор комментариев, краткая документация по программе, краткая документация по выбранному свойству....
- Обновление состояния QAction(s)
Кроме этого происходят определенные перерасчеты и обновления данных.
И все это завязано на выбранный элемент(задачу) данного списка, и текущие элементы иерархически вложенных данных.

И вы мне предлагаете ради одного из представлений отвязать текущий элемент от данных?

[BRE]

Модели в Qt является по сути хранилищем данных с универсальным интерфейсом, в котором можно хранить как табличные, там и древовидные структуры. Они отвечают только за это.
Ты же не требуешь, что бы сервер баз данных хранил выбранные записи для каждого пользователя, это не его задача. Ты же не требуешь от QList возможности отметить несколько элементов и удалить вызовом одного метода. Все это только хранилища, они не должны обеспечивать какой то дополнительный функционал.
На счет селекции, храни модель, храни селект-модель для нее. Если удобней (а мне кажется будет удобней) объедини их в одну сущность и поддерживай актуальность в ней. Все изменения делай через интерфейс этой сущности, тогда никто из вне не сможет изменить данные в модели без изменения селект-модели. Добавь в сущьность необходимые сигналы, которые будут вызываться при определенных изменениях, слоты, которые будут модифицировать состояния.

[spectre71]

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

Модель - не является хранилищам данных как контейнер. Она является интерфейсом, в некотором смысле адаптером.
Просто хранилища - контейнеры. Какие сущности  должна представлять модель зависит от задачи и возможностей View. У меня одной из таких сущностей является текущий элемент, но к сожалению модели QT это не поддерживают, как и не обеспечивают интерфейс для перемещения данных.
С сервером баз данных неудачный пример, там можно хранить для кого хочешь, что хочешь и как хочешь, и обеспечивать нужную функциональность в зависимости от задачи и возможностей СУБД.
QList - не модель, а контейнер и к делу никак не относиться.

На счет селекции, храни модель, храни селект-модель для нее. Если удобней (а мне кажется будет удобней) объедини их в одну сущность и поддерживай актуальность в ней. Все изменения делай через интерфейс этой сущности, тогда никто из вне не сможет изменить данные в модели без изменения селект-модели. Добавь в сущьность необходимые сигналы, которые будут вызываться при определенных изменениях, слоты, которые будут модифицировать состояния.

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

[ритт]

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

[spectre71]

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

Если речь о моей модели(которая в примере), то она как раз и находится в 2х View, QTableView & PipelineEditor(мой компонент). И обязана иметь везде одну и ту же селекцию.