Russian Qt Forum

Делаю:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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



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

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

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

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

Только отчасти, в случае когда не предпологается изменение данных при изменении селекции этот подход верен.
В моем случае это не так.
Данные, например клас TProject, имеет int itemIndex(void) и void itemIndex(int). Селекция во View всегда должна соответствовать itemIndex. При смене селекции должен устанавливаться itemIndex(int), а это мало того что тяжелая операция, она еще и не простая в плане синхронизации с другими данными. itemIndex может быть изменен как через View, так и из других мест! При удалении элементов из списка TProject может измениться itemIndex, в зависимости какой элемент удаляется, и механизм того как изменяется itemIndex встроен в TProject.
Теперь смотрим что получается:

C++ (Qt)
 
......
 
  ProjectView = new TTableView(MainWindow);
  ProjectModel = new TProjectModel();
  ProjectView->setModel(ProjectModel);
  QObject::connect(ProjectModel, SIGNAL(signalUpdateSelection(const QModelIndex)), ProjectView, SLOT(setCurrentIndex(const QModelIndex)));
  QObject::connect(ProjectView->selectionModel(), SIGNAL(currentRowChanged (const QModelIndex &, const QModelIndex &)), ProjectModel, SLOT(onCurrentChanged (const QModelIndex &, const QModelIndex &)));
 
......
 
  ProjectModel->setProject(Project);
  ProjectModel->updateSelection();
 
......
 
void TProjectModel::onCurrentChanged (const QModelIndex & current, const QModelIndex & previous) {
  if(LockUpdateSelection) {return;}
  if(!current.isValid())  {Project->itemIndex(-1); return;}
  Project->itemIndex(current.row());
}
 
void TProjectModel::updateSelection(void) {
  if(Project->itemIndex() < 0) {return;}
  LockUpdateSelection++;
  emit signalUpdateSelection(this->index(Project->itemIndex(), 0, QModelIndex()));
  LockUpdateSelection--;
}
 
void TProjectModel::beginDeleteTask(int ind) {
  LockUpdateSelection++;
  beginRemoveRows(QModelIndex(), Project->itemIndex(), Project->itemIndex());
  LockUpdateSelection--;
}
 
void TProjectModel::endDeleteTask(void) {
  endRemoveRows();
  updateSelection();
}
 
.........................
 
void TPLProject::itemIndex(int ItemIndex) {
  CurTask   = task(ItemIndex);
  this->ItemIndex = ItemIndex;
  for(int i=0; i<TaskOrdered.count(); i++) {
    if(TaskOrdered.object(i) == CurTask) {
      TaskOrdered.move(i, 0);
      break;
    }
  }
  sync()->onTaskIndexChange();
}
 
void TPLProject::deleteTask(void) {
  if(ItemIndex == -1) {return;}
  resetTask();
  if(Task.count() == 1) {
    propertyEditor()->tree(NULL);
    clear();
    return;
  }
  int rem_ind  = ItemIndex;
  sync()->projectModel()->beginDeleteTask(rem_ind);
  try {
    if(ItemIndex == Task.count()-1) {ItemIndex--;}
    for(int i=0; i<Task.count(); i++) {
      if(task(i) == CurTask) {continue;}
      task(i)->deletePipe(CurTask);
    }
    Task.remove(rem_ind);
    for(int i=0; i<TaskOrdered.count(); i++) {
      if(CurTask != TaskOrdered.object(i)) {continue;}
      TaskOrdered.remove(i);
      break;
    }
    CurTask = task(ItemIndex);
  } catch (...) {
    sync()->projectModel()->endDeleteTask();
    throw;
  }
  sync()->projectModel()->endDeleteTask();
 
  updateScreenMax();
  pipelineEditor()->updateFieldSize();
  pipelineEditor()->repaint();
  propertyEditor()->tree(program()->tree());
}
 
 

Посмотри в TPLProject::deleteTask вызов метода модели  beginDeleteTask(rem_ind); и сам метод в модели!
Если не использовать блокировку, то получается:
при вызове beginRemoveRows(QModelIndex(), Project->itemIndex(), Project->itemIndex()); меняется селекция и вызывается TPLProject::itemIndex(int) и возникают большие неприятности.


Причем здесь персистент индексы, я не понял?