Здравствуйте, SaZ, Вы писали:

SaZ>Здравствуйте, _hum_, Вы писали:

__>>например, организовать эдитор, у которого бы был элемент, выходящий за пределы поля ячейки, но при этом не выходящий за пределы границы таблицы (то есть, его геометрия зависела бы от того, в каком положении относительно границ таблицы располагается ячейка). как вариант:

__>>Image: 2b87ad284cf2.png

SaZ>Я уже говорил — вы хотите нетривиальную функциональность.

а по мне, так вполне естественную (а потому тривиальную) для таблиц

SaZ>Создаёте эдитор в ячейке + создаёте сверху виджеты, которые вам нужны.

где, в createEditor (речь же шла о нем)?

__>>во-первых, там во втором аргументе QStyleOptionViewItem, в котором по документации непонятно какие координаты содержатся — по крайней мере, ничего, кроме

SaZ>Координаты вашей ячейки. Потому что это user-friendly, если ваш виджет впишется в ячейку. В противном случае вьюхе, вероятно, придётся растягивать столбцы.

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

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

SaZ>У вьюхи есть метод, чтобы по индексу получить координаты. Зная индекс текущей ячейки можно получить индекс и геометрию соседней. А саму вьюху можно передать параметром, через композицию, в делегат. Это нормально, т.к. один экземпляр делегата не нужно вешать на разные вьюхи.

да, но это уже получается обходной путь с привлечением сторонней информации, тогда как, по логике, ее же можно было взять и из parent, если бы было известно, что им является QTableView (подчеркиваю, я не говорю, что именно так надо было бы делать разработчикам qt, я лишь обращаю внимание на то, что пространное описание в документации может наводить именно на эту мысль, и тем самым дезориентировать программиста [это все к вопросу о корявости докумнетации]).

__>>...человек, впервые ее читающий, сбивается с толку фразами "parent используется для настройки того, как будет отображаться эдитор"...

SaZ>Где (а точнее, на чём), а не как.

ну, смотрим первоисточник и убеждаемся, что именно "как", а не "где"

QWidget * QItemDelegate::createEditor(QWidget * parent, const QStyleOptionViewItem & option, const QModelIndex & index) const

Reimplemented from QAbstractItemDelegate::createEditor().

Returns the widget used to edit the item specified by index for editing. The parent widget and style option are used to control how the editor widget appears.

__>>изначально-то с этого и началось — я указал, что документация к qt, несмотря на ее объемность, намного хуже написана, чем тот же msdn, а не вел речь про целесообразность организации схемы создания эдитора делегата.

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


неохота переходить на новое и неприятие документации — совершенно разные вещи. в мсдн соотношение полезная информация/объем текста намного выше, чем в qt. там все сразу навиду и по делу. например, в описании функции — в столбец перечисление входящих параметров, их назначений, далее, возвращаемое значение, далее, примечения, далее пример. все! а в qt надо шарить глазами, чтобы найти, что же данный аргумент означает, и очень часто это так и не удается сделать из-за того, что все ограничивается фразой типа той, что в createEditor.

если проводить аналогию, то такое ощущение, что msdn писали специалисты, а qt-доки — самоучки-любители, не имеющие представления о системности изложения информации.