Как правильно реализовать такую прокси модель?

yoghurt grondek

делегаты?

Что?

Каким они там боком?

свой делегат на отображение во вьюхе.

Обновил топик.

В общем надо из одной из ячеек текущей строки взять структуру и отобразить в таблице.

ну так никто не мешает сделать делегат вьюху табличную.

Зачем здесь прокси? Это разные модели вообще.

Создай отдельную модель для таблицы и свяжи её сигналами-слотами с treeview - когда выбирается индекс, меняется содержимое табличной модели.

Хм...
В общем-то да...
Мне просто ранее советовали прокси использовать
Ну ладно, попробую сейчас свою модель зарулить.

1. Единая модель для TreeView и TableView. Структуру хранишь как дочерние индексы в дереве в две колонки.

2. По выбору индекса в TreeView для TableView делаешь setRootIndex на выбранный индекс, тот который предок для твоей структуры.

3. PROFIT! В TableView отображаетмся то, что тебе надо

Один из столбцов QTreeView содержит структуру

У тебя столбцы должны не содержать структуры, а лишь их отображать.

Немного не понял 1.

У меня модель сейчас возвращает такие элементы в строке:
Строку|Строку|Структуру Естественно все в виде QVariant'ах.

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

Ну оно их не отображает, сейчас подробнее напишу:
Есть модель со следующими столбцами:
Строка|Строка|Структура

В дереве показываю первые 2. Теперь надо как-то 3 отобразить в виде таблицы в QTableView.

Пары <наименование поля> : <значение поля> в модели показываются как дочерние индексы третьего столбца. То есть модель такая:

Строка | Строка | Неважно что 
                       |
                       -->  <наименование поля> : <значение поля>
                       -->  <наименование поля> : <значение поля>
                       -->  <наименование поля> : <значение поля>

Соответственно, в TreeView третий столбец ты не показываешь, а в TableView третий стоблец стает rootIndex и показываются его дочерние индексы.

В смысле не столбец, а данные ячейки в данной строке находящийся на месте столбца.

Честно говоря это тяжело осознать без примера, но я в принципе понимаю.

Т.е. вы предлагаете сделать такой граф:

|-Строка | Строка | Неважно что 
|                       |
|                       -->  <наименование поля> : <значение поля>
|                       -->  <наименование поля> : <значение поля>
|                       -->  <наименование поля> : <значение поля>
|
|
|-Строка | Строка | Неважно что 
|     |                  |
|     |                  -->  <наименование поля> : <значение поля>
|     |                  -->  <наименование поля> : <значение поля>
|     |                  -->  <наименование поля> : <значение поля>
|     |
|     |
|     |-Строка | Строка | Неважно что 
|                             |
|                             -->  <наименование поля> : <значение поля>
|                             -->  <наименование поля> : <значение поля>
|                             -->  <наименование поля> : <значение поля>
|
|
|-Строка | Строка | Неважно что 
                       |
                       -->  <наименование поля> : <значение поля>
                       -->  <наименование поля> : <значение поля>
                       -->  <наименование поля> : <значение поля>

И опять покажу вот сюда: http://qt-project.org/doc/qt-4.8/model-view-programming.html

Одна модель (ФС) на два разных представления.

А «структура» - это что? Некий объект со своими полями?

Самый тупой вариант - ловить сигнал «выделение объекта» в дереве, получать по нему нужный объект (завернутый в QVariant через index.data()) или каким-нибудь ещё способом, и сообщать его в свою модель для QTableView (которая знает, как данный объект представить в виде набора строк/столбцов).

Будет просто и будет работать. Возможно, в твоем случае с твоей изначальной моделью большего действительно не надо.

У него, по всей видимости, листья (которые <наименование поля> : <значение поля>) не входят в саму древовидную модель, а просто представлены как какой-то свой объект.

НУ и пусть лежать как объект, прокси может их представлять их в виде листьев.

Это тоже верно, но может быть слишком лихо =)

Да да да. Эти данные используются для дальнейших расчетов.

Спасибо за помощь в любом случае.

Да. В примитивном варианте ты из своей структуры строишь таких детей для «неважно что».

В сложном, но более правильном варианте делается так:

В «Неважно что» лежит твоя структура и в модели нет детей «<наименование поля> : <значение поля>».

Далее поверх строится прокси модель, которая твою структуру отображает как детей третьей колонки в виде «<наименование поля> | <значение поля>» (как у тебя на рисунке).

И уже эта прокси модель отображается в дереве и таблице.

То есть:

Модель:

|-Строка | Строка | Структура
|                       
|-Строка | Строка | Структура
|     |
|     |-Строка | Строка | Структура 
|
|-Строка | Строка | Структура 

Прокси модель:

|-Строка | Строка | Структура 
|                       |
|                       -->  <наименование поля> : <значение поля>
|                       -->  <наименование поля> : <значение поля>
|                       -->  <наименование поля> : <значение поля>
|
|
|-Строка | Строка | Структура 
|     |                  |
|     |                  -->  <наименование поля> : <значение поля>
|     |                  -->  <наименование поля> : <значение поля>
|     |                  -->  <наименование поля> : <значение поля>
|     |
|     |
|     |-Строка | Строка | Структура 
|                             |
|                             -->  <наименование поля> : <значение поля>
|                             -->  <наименование поля> : <значение поля>
|                             -->  <наименование поля> : <значение поля>
|
|
|-Строка | Строка | Структура 
                       |
                       -->  <наименование поля> : <значение поля>
                       -->  <наименование поля> : <значение поля>
                       -->  <наименование поля> : <значение поля>

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

Так что не парься и строй модель как ты нарисовал выше

Самое простое и рабочее я уже выше описал :) и E.