Russian Qt Forum

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

О чём я? О  функции (в cpp):
    NOTE: This function is a duplicate of qt_graphicsItem_highlightSelected() in qgraphicsitem.cpp!

    NOTE: This function is a duplicate of qt_graphicsItem_highlightSelected() in
          qgraphicssvgitem.cpp!

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

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

Qt не стремится к "минимуму виртуалов", разработчики стремятся правильно проектировать классы, и не делать виртуальными методы те, которым это не нужно.

Ну это у вас наследование часто оказывается неудачным. :)
Все остальные спокойно пользуются этим основополагающим свойством языка. Его именно для наследования и придумали.

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

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

Ура, ура. Нашёл. В моем реальном проекте
QGraphicsItemGroup *   QGraphicsScene::createItemGroup(const QList<QGraphicsItem *> & items)

Метод возвращает конктетный класс (объект класса), мне же нужен мой. Он может возращать данный тип, в коллекции по другому не получится, но вот внутри мне нужно new МойГроупКласс. Я не спорю, данный метод не обязательно должен быть виртуальным, но вот вызывать протекстед виртуальный createItemGroup не помешало бы.

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

Ну хорошо, посмотрим  :)

Ну, эта функция рисует рамку. Вы кляцнули на что-то, и рамка появилась (элемент выделен). Эту рамку нельзя заменить на свою, что уже плохо. Негодования нету, уже привык давно. Но а теперь, я создаю свой элемент коллекции. И что же мне делать, точно также копировать этот код и писАть  - скопировать с Qt. Мало того, не существует возможности заменить рамку на свою, приходится так извращаться, что ужас. И эта не та "рамка", которую не стоит изменять, дабы не сбить пользователя с толку.

Чего ж не существует? Смотрим исходник

C++ (Qt)
void QGraphicsPolygonItem::paint(QPainter *painter, const QStyleOptionGraphicsItem *option, QWidget *widget)
{
    Q_D(QGraphicsPolygonItem);
    Q_UNUSED(widget);
    painter->setPen(d->pen);
    painter->setBrush(d->brush);
    painter->drawPolygon(d->polygon, d->fillRule);
 
    if (option->state & QStyle::State_Selected)
        qt_graphicsItem_highlightSelected(this, painter, option);
}
 

Ну, стало быть, наш paint

C++ (Qt)
void MyPolygonItem::paint(QPainter *painter, const QStyleOptionGraphicsItem *option, QWidget *widget)
{
    bool selected = (option->state & QStyle::State_Selected) != 0;
    option->state &= ~QStyle::State_Selected;
 
    QGraphicsPolygonItem::paint(painter, option, widget);
 
    if (selected) {
      option->state |= QStyle::State_Selected;
      MyDrawSelect(painter, option, widget);
    }
}
 

Ну или фильтрок навесить, тогда можно и не наследоваться, и рисовать выбор для всех айтемов. Это что, титанические усилия?  :) Конечно было бы еще лучше иметь это в стиле (как для виджетов). Но это никак не виртуал.

Да, если нужно МойГроупКласс (вместо QGraphicsItemGroup) - придется самому, скопировать из исходников и заменить new. Ну или сразу template. Но объявление этого метода виртуалои все равно не помогло бы.

Ну, стало быть, наш paint

C++ (Qt)
void MyPolygonItem::paint(QPainter *painter, const QStyleOptionGraphicsItem *option, QWidget *widget)
{
    bool selected = (option->state & QStyle::State_Selected) != 0;
    option->state &= ~QStyle::State_Selected;
 
    QGraphicsPolygonItem::paint(painter, option, widget);
 
    if (selected) {
      option->state |= QStyle::State_Selected;
      MyDrawSelect(painter, option, widget);
    }
}
 

Ну или фильтрок навесить, тогда можно и не наследоваться, и рисовать выбор для всех айтемов. Это что, титанические усилия?  :) Конечно было бы еще лучше иметь это в стиле (как для виджетов). Но это никак не виртуал.

Давайте так, чтобы это не превратилось в воду, как сказали в  прошлой теме.
Здесь же вопрос стоит не "как", а "почему".
Понятно, убираем флаг (чтобы сдуру базовый класс не перерисовал), рисуем свой, восстанавливаем флаг (кстати, из коробки работать не будет, там ещё есть завязки) . Вот про эти извращения я и говорил. Если Вы считаете это нормальным, тогда чтож, данный топик не имеет смысла.

Так и работаем, не жалуемся. Но это, скажем так, курилка, и мысли вслух просто.
Так вот, вопрос -  зачем мы должны так извращаться. Какие накладные расходы несёт данный метод, если бы его сделать протектед виртуал? При чем здесь разные части библиотеки? Если это сделано так, я точно уверен, что из за политики Qt, а не целесообразности программирования.
Это все риторические вопросы.
Я ничего не добиваюсь, но эта интересная особенность вовсе не особенность, а целенеправленная фигня.

И стили здесь не причем. Стили - это стили, а мне нужно изменить поведение рамки в зависимости от моих условий. К примеру - рисовать розочки по внутренним углам.

P.S. Кстати, что такое фильтрок

Я считаю это абсолютно нормальным использованием наследования.

Какой "данный метод"? QGraphicsItem::paint и так виртуал, а если разговор о QGraphicsScene::createItemGroup, то уже говорилось - там хоть виртуал, хоть нет, не поможет.

Так что на данный момент не видно в чем же "закрытость" Qt. Ни одного реального примера "плохо-расширяемости" Вы так и не привели. Выглядит как типичная мечта люмпена "как бы ни хрена не делать и зарплату получать"  :)

В какую то другую сторотону всех понесло. Люмпена какого-то привели. Если Вы считаете, что копирование полностью функции это "хорошая" расширяемость.... Ну чтож, тогда нужно и QObject туда копировать. Если это не кричащий пример плохой расширяемости, то я пас. Чего Вы защищаетесь, никто ни на Qt, ни на Вас не нападал. Едрить его налево.....
Не знаю, кем говорилось. Но поможет, очень даже.

Я понял. Подытожу. Qt самая лучшая библиотека (фреймворк), лучше ничего нету, а кто ей не умеет пользоваться, у того руки кривые.

P.S. И таки да, Ваш код скопировал, сразу штука баксов капнула.

Тащемта, так и есть.

Ну к числу защитников Qt я никогда не принадлежал, что может подтвердить хотя бы автор предыдущего поста.  

О какой ф-ции Вы говорите? qt_graphicsItem_highlightSelected с которой начали тему? Или о QGraphicsScene::createItemGroup? И на то и на другое я ответил. Если Вы не поняли - или поняли. но не согласны - пожалуйста, высказывайтесь, и я попробую ответить. Но не надо "ходить кругами" повторяя одно и то же  

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

Если убрать эту ф-цию напр из qgraphicssvgitem.cpp, то где она должна быть? Для нее просто не находится подходящего места (во всяком случае пока), поэтому проще дублировать. Заметим что ф-ция наглухо закрыта, пользователю ее не обещали.

Ну, её можно было бы засунуть в static protected метод класса QGraphicsItem, тем более что она не использует данные класса, пользователь данной функции ничего бы поломать не смог.
Если рассмотреть подсистему QGraphicsView (по названию каталога исходников), то там практически она вся закрыта. Добавлять новый функционал очень сложно и при том она ещё и глючит кое-где. Я, если честно, не понял вашего решения с groupClass (придется самому, скопировать из исходников и заменить new). Да, это понятно, но извените, топик как раз и называется - закрытость Qt, это ли не показатель закрытости? Тем более, вы долны понимать, что это решение (теоретически) может нехило выстрелить при изменении версии Qt. Также не понятен вопрос лицензионности - имеем ли мы право такой копипастой заниматься (May keep Qt modifications private, хотя это вторично). Да и это частичное решение, ведь QGraphicsScene гуляет в виде класса везде, и нам прийдётся делать приведения типа, чтобы вызвать свою функцию, что не такой мелкий геморой, если размазать по всему проекту с десятками таких "если".


Функция байт в байт. Никакой работы делать не нужно, если написание пару буков есть работа. Ведь смотрите как получилось у них. Была работа со сценой, и тут бах, в отдельном модуле нужно реализовать такой же функционал. Ведь мы понимаем, что модуль - это административное понятие (в данном случае). Что делать? Та просто что недоступно, скопируем.

И ваша (или  моя)  реализация функционала нового (такой же модуль в отношении Qt), тоже требует тупого копирования.

Нельзя.

Можно.

По поводу qt_graphicsItem_highlightSelected
Тогда придется делать ее доступной для пользователя, а они как раз этого и не хотят. Понятно почему (см саму ф-цию) - она аж рисует QRect пытаясь подобрать подходящий цвет и толщину линии для стандартных айтемов. Т.е. с любым нестандартным она уже будет рисовать невпопад. А сделать ее недоступной не выходит т.к. либы разные.

А в Вашем изложении выглядит как будто утерян громадный ф-ционал! :) Ну ведь все равно Ваши айтемы Вы же и рисуете - ну Вам и карты в руки как рисовать selected, чего плакать о потерянной рамке?

Теперь по поводу ctreateItemGroup
Не показатель если подумать "а как лучше" (больное место практически любой критики). Вы предлагаете сделать это виртуал

virtual QGraphicsItemGroup * QGraphicsScene::createItemGroup(const QList<QGraphicsItem *> & items) 
 

То що це воно дало? Вы все равно не сможете разумно перекрыть чтобы воспользоваться оригиналом - он вернет указатель на QGraphicsItemGroup, а нужен на потомок. А реализовать весь ф-ционал самому - виртуал бесполезен.

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

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

Агаг, сижу я здесь значит на форуме, и не делаю ничего, жду пока Qt его изменит. Я разве вас спрашивал, как мне это сделать? Разве я инетесовался реализацией? Нет, я интересовался ответом на вопрос "почему". Значит рамку они боятся, что пользователь поломает, а метод paint не боятся выставлять.  Я ещё раз повторюсь, из за такой закрытости действительно абслютно все график итем прийдётся реализовывать самому (выше писАл как). Да и где вы увидели, что рамка расчитана на стандартные итемы, если туда пихают картинки. Как может картинка быть страндартная, она может в конце концов быть квадратом Малевича.

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

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

Мои примеры все примитивны. Есть шаблоны (не С++, а проектирования) - если коллекция - все методы добавления (ещё лучше плюс протектед создания объекта) должны быть виртуальны. Ну куда по другому. Все колекции так построены. А тут не, фиг вам. Это не крик души, работаем с чем работаем, но вы на тему топика посмотрите - зачем так?

Про NVI, вы, конечно, не в курсе?

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

Но что бы Вы хотели? Как Вы себе представляете нормальную "систему"? Чтобы все шло с пол-пинка и именно так как каждый хочет? Напр хочу чтобы я нарисовал свой graphics item, а мне его автоматом рисовали selected. И чтобы это выглядело разумно и опрятно для любого моего айтема.

А не зажрались ли? Я вот еще помню как делал ListBox на Mac classic. Создается новый проект (да-да, для каждого ListBox'а). Там общаемся с "List Manager" (была дока с Pascal примерами) через API и компилим это как "code resource" и включаем это в ресурсы основного - и вот, все работает! И никто не вякал, и, кстати, контролы получались оригинальными и интересными, сейчас уже таких не сделаю. А тут... букварь читается кое-как, в падлу исходники глянуть, видеоуроки им подавай! Чем больше "дается" - тем "мельче" программист.

Не понял. Разве push_back (и.т.п.) виртуалы? Где  ???

Слышал много, но вот примера хорошего пока не видел. Дайте ссылку (а еще лучше поясните на своем примере)
 

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

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

Пример два (уже лучше, но еще не NVI)

Пример три (еще лучше, NVI)

Ну и напоследок могу сказать, что с NVI виртуалки можно выносить в приватный класс и добавлять\удалять их как душе угодно:

Ага, const & уже не считается хорошим тоном. Ах как переменчива мода  :)

Такого видел много, но так и не понял в чем "крутизна". Не вижу что плохого если сделать open виртуалом? Тем более он может понадобиться и без установки url. Да, невиртуальная обертка иногда полезна, туда можно скинуть кое-какой ф-ционал, пусть нечасто. Но расширяемось виртуалов остается та же самая. Вот Вы привели пример 2 наследников c QAction и QMenu. Какие-то действия имеют смысл для QMenu но не для QAction (или наоборот). Как это будет выглядеть в общей схеме и как здесь поможет NVI?

Спасибо

Ну лень же писать было:( Хотя, вот столпы с++ говорят, что по значению может быть лучше в свете с++11.


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

Действия для QMenu будут только в обертке, оборачивающией QMenu.
NVI тут помогает тем, что а) полностью скрывает реализацию от пользователя (он видит только пропертю text) б) позволяет добавлять в базовый класс новый функционал (допустим, пропертю toolTip), не ломая бинарную совместимость (мы не можем добавить новую виртуалку, а геттер\сеттер\сигнал - запросто) в) (в данном примере) не позволяет пользователю оверрайдить нашу виртуал ф-ию.
Если вам аргумент про бинарную совместимость кажется надуманным, могу рассказать чудную историю как я искал баг, оказавшийся в том, что плагин был собран с gcc 4.7, а базовая либа - с 4.8, а там unordered_map бинарно несовместимы (причем мап никто напрямую не передавал, у либы вообще сишный интерфейс был)

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

Расскажите, может тогда станет яснее (пока не очень)

Ссылочку можно напочитать?

Не. Не зажрался. Оценка времени. Времени выполнения задачи. Даже для "вольных художников" она важна. Сделать таск намбер 1 занимает ничего. Такой же таск намбер ту (простой как 2 копейки) упирается в нерасширяемость библиотеки, нелогичного поведения. Если таск 1 на ура, такой же  примитивный 2-й упёрся в такую стену, что все остальное нужно сметать и переписывать. Где здесь зажратось, когда ты не можешь определить даже время выполнения задачи. Всегда есть какая-то закрытая часть, всегда есть мааааааааааааленькая фишечка, тупая, но она закрыта.
Могу ли я привести примеры - могу, но тогда я хочу содержательного анализа от людей "почему так", тем более, приведение этих примеров требует вникание в тематику... И так далее и так далее.............

Это часто встречается и в др темах, "элементарный пример" и все такое. Кстати "элементарно" - совсем не значит "просто" (как полагают борзописцы). Но почему Вы решили что это "просто"? Потому что для схожей задачи 1 надо было написать неск строк. И что? То же самое средствами API (без Qt) могло вылиться не в 1 сотню строк. Видимо те кто считает все "простым" по этой дорожке не ходили. Отсюда и отросшая "хотелка", только от этого ничего не изменится. Хотите на здоровье, а выучить все равно придется

Нет нет, мы говоря про тематику и видя интерфейс библиотеки  принимаем решение, что это ничего не стоИт в плане разработки, это даже не расширение функционала и не хотелка, это просто банальная вещь и БАХХХ. Когда начинаешь сложную вещь разрабатывать (в плане компонента Qt)  - всё гораздо проще - у тебя есть минимальная зависимость и всё зависит от тебя.  Ладно. Воду уже льём. Не может быть две простые вещи - "покрасить в зеленый цвет и повернуть направо" отличаться временем разработки на порядки (в десятичной системе)

Подытожу вашу мысль: "Идеального ничего нету, и да, вы должны настолько досконально знать внутреннюю реализацию библиотеки, что подсознание вам должно выплёвывать автоматом, куда двигаться и на что обращать внимание".  Жалко, что вы не постарались "занять" мою позицию и посмотреть с её точки зрения. Ведь Qt даёт нам исходники, что уже нас "ограничивает", ведь мы туда подсматриваем, что есть плохим тоном, ведь мы должны "скрывать" реализацию от всего остального. И таки "офигиваем" там (по хорошему или плохому подоводу), но не в assistante.

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

Ладно, вот отрицательный пример из моей последней практики. Пришлось попариться основательно с QListWidget. Причина - не устроило как рисуется выбранный айтем. Там иконка рисуется QIcon::Selected что вполне норм если иконки однообразны. Но у меня каждая уникальна, создается программно. Поэтому если она "отливает голубизной" (как делает Qt) - это совершенно не воспринимается как "выбрана". В моем случае выделение нужно показать рамкой (а не тонированной иконкой). Ну + рисование текста, в общем пришлось попыхтеть неск дней.

Варианты ответа:

1) Плохо искал, надо было.. <решение>
2) Вот она, "закрытость" Qt" неск дней на "простейшую" вещь!!!
3) Ваш вариант

Я там свой ответ предыдущий обновил...., ваш не видел.

Какие парадоксы, топик начинался с того же подсвечивания выделенного элемента.
У меня нет желания изменить мир, в т.ч. и Qt, тема в курилке (говорилке), просто мысли вслух. Мысль проста - а был бы метод protected virtual QListWidgetItem::selectedView подсвечивания этого самого итема, насколько бы проще было бы вам и мне и самое главное, насколько это было бы красивое решение.

Так что мой ответ номер 2.

Вооот. Критиковать все мастера, и хорошо еще если корректно как Вы - а то многие начинают "кидаться какашками" и все такое :) Но когда дело доходит до конструктива (т.е. а как же надо/правильно) - ни одного вумного критика в упор не видно  :)

То что Вы предлагаете есть и легко доступно, просто называется по-другому

C++ (Qt)
MyDelеgate::paint( ... )
{
// здесь какой-то свой код
...
 
  QStyledItemDelegate::paint(...); 
 
// здесь опять какой-то свой код
...
}

Это виртуал (которого Вы так хотели). Пожалуйста, перекрывайте. Увы, это ничего не дает. Вызывать оригинал - получаю "голубую" (выбранную) иконку. Нарисовать иконку самому - а где? Ее позиция вычисляется стилем, это придется повторить. Но обвести ее рамкой (как мне нужно) все равно не выходит - ведь стиль ни о какой рамке не знает и никакого места под нее не оставил.

Как видим, "больше виртуалов" не помогает. А как надо было правильно? Лично я просто не знаю. Но без ответа нытье смысла не имеет  :)

Вот тут (http://www.youtube.com/watch?v=eR34r7HOU14) с 40й по 50ю минуту он рассказывает про передачу параметров. Дальше пока не смотрел, мб ещё есть. Смысл в том, что когда мы передаем ссылку, компилятор (оптимизатор) не знает, владеет ли он этим адресным пространством в одиночку и у него мало маневра для оптимизации.

Вот тут (https://github.com/CppCon/CppCon2014/blob/master/Presentations/Back%20to%20the%20Basics!%20Essentials%20of%20Modern%20C%2B%2B%20Style/Back%20to%20the%20Basics!%20Essentials%20of%20Modern%20C%2B%2B%20Style%20-%20Herb%20Sutter%20-%20CppCon%202014.pdf) Саттер рассматривает примеры и говорит обратное, но вне привязки к оптимизации. При этом он говорит, что в конструктор лучше передавать копию, так как мы и так будем копировать.

Вообще-то, есть QItemDelegate, который не дергает стиль, а рисует всё сам. Там чуть больше виртуалов, в частности, есть ф-ия drawDecoration, к-ая рисует иконку.
Другое дело, что иногда функционала даже этого класса мало и надо лезть ему в кишки и копипастить. Но скопипастить его относительно легко, у него нет зависимостей от внутренностей Qt; а дальше его можно менять как душе угодно.
В продолжение темы делегатов - мне надо было сделать текст, к-ый бы элайдился в любом месте, а не по словам (как сейчас). Тоже пришлось повозиться. Причем фича вроде бы банальная, но в Qt ее не включить - придется делать еще одну версию стилеопции, что не очень красиво.

Не обижайтесь, но получается "сами с собой поговорили". То, что я предлагаю, не есть легко и доступно, потому что его вообще нет. Как вы сами сказали, метод paint не даёт ожидамего результата т.к. все остальное "размазано" по классу при проектировании. Слушайте, это мой крик души, а не ваш, не забирайте у меня топик :) Шучу, шучу. Дарю.

Больше виртуалов конечно же помогло, т.к. знали бы, для чего он.

Все равно считать пр-ки надо самому, рамку самому и текст - тоже самому. Последнее оказалось тоже непросто, см здесь (http://www.prog.org.ru/index.php?topic=28641.msg209625#msg209625). Выходит со стандартного/стилед делегата я ничего не поимел (а xотелось бы).

Уже не в первый раз привожу пример где виртуал ничем не помогает. Более того, в данном случае он даже есть (присутствует). Однако Вы опять утверждаете обратное - и опять бездоказательно. 
ну пока это все что я понял из Вашей аргументации  :)

Видно мы не хотим услышать друг друга. Вы видели где нибудь private virtual метод? Нет, т.к. это бессмысленно. Если бы ваш класс разрабатывался с учём отдельного метода, реализующего подсвечивание, с учётом того, что его могут переопределить в дальнейшем, то очень даже помогло. Никто не предлагает делать всё виртуальным. Повторюсь с самого начала: при разработке "моего" класса и "вашего" класса были сознательно спратана эта реализация, чтобы вы без гемороя не могли её изменить. Вот в чем смысл топика. В виртуал - это всего лишь одна из возможных реализаций (она больше в духе Qt), дело не в ней, приципились к этой виртуал. Да хоть функцию передавайте туда перерисовки. Это не важно, это всего лишь деталь реализации.

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

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

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

Мне кажется, что там (внутри QItemDelegate) где-то есть ф-ия, к-ая как раз делает то, что вам надо:) По крайней мере, очень похоже - там построчный элайд как раз (чтобы влезть в высоту).


Если предоставить всем подряд доступ к имплементации, то эту имплементацию нельзя будет поменять. Qt - это чуть ли не единственная библиотека, к-ая за последние Н лет (с 4.0 так точно) сломала бинарную совместимость полтора раза (1 раз сами и 1 раз дебианщики, хотя могли и не ломать). Другие либы кладут большой болт даже на сорс-совместимость. Вы хотите, чтобы ваш код ломался при переходе на новую версию Qt?
Могу рассказать ещё историю. Во времена Qt4.6-4.7 было (условно) 3 реализации гуйни - под мак, венду и линупс. Текущая архитектура позволила АБСОЛЮТНО ПРОЗРАЧНО добавить 4ю реализацию - через Lighthouse (посредством плагинов). Сейчас остались только плагины; но сам проект мог быть невозможен, если бы нельзя было менять реализацию, сохраняя API.

О, первый шикарный ответ "почему" (без иронии с моей стороны).
Чтобы сузить наш дискус, давайте отбросим бинарную совместимость собственных проектов, как вы понимаете, это конечный продукт в 99.9%, который её не требует.

Итак, вывод - разработчики Qt суровы и следуя стопам Линуса говорят, что главное совместимость. Не берусь судить, какая стратегия  лучше (менять айпи, все и так привыкли к другим проектам, что они меняют, либо следовать своей стратегии), но у них это работает.

Но тут есть одна засада на ваш вопрос.
Конечно не хочу. Но данная стратегия также будет ломать код, ведь что приходится делать (очень утрированно) ctrl-c; ctrl-v кода, который не участвует в этой самой приславутой бинарной совместимости, но запросто может поломаться при переходе на новую версию. Да, Qt  консервативно, но время летит быстро.

Честно сказать, значение этой самой бинарной совместимости (как для меня) уж сильно преувеличина. Хочу спросить у вас - а как же This function introduced in Qt 4.x.x, которым пестрит ассистант. Было бы интересно, если бы вы "коротко развернули" эту тему, т.к. бинарная совместимость для меня это зверь, которого никто не видел, в том плане, что у всех проектов есть зависимости от версий.

P.S. Видимо я не понимаю или "не хочу понять". Но если создали целую ОС (Gentoo к примеру), где все эти зависимости разруливаются в онлайн режиме компилированием всего и вся......

Очень даже смысленно, для того же NVI 

Пожалуйста конкретнее. Какое решение Вы предлагаете? Что разработчики должны изменить чтобы было удобнее? Без этого получается просто капризный ребенок
:)

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

Введение новой функции не ломает бинарную совместимость. Совместимость ломают - изменение структур (добавление, изменение порядка полей), изменение сигнарутры ф-ии (но можно добавлять оверлоады, если ф-ия уже их имеет), добавление виртуальных (!) функций (но иногда можно добавить override туда, где его не было, см QThread::run), нельзя менять порядок виртуалок. Нельзя удалять ф-ии/классы, менять инлайновость ф-ий, добавлять/удалять const. Вроде, почти всё)

А вот С API не имеет ни одной такой злополучной проблемы  :)
Собственно вокруг чего сыр-бор. Разработали какое-то API со всякими вумными классами, ну ладно, на этом API другие нахрюкали плагинов (к примеру). И вот теперь надо базовое API обновить, но так чтобы плагины ходили. В общем
Правильно ли я понимаю?

C API имеет те же проблемы - нельзя менять структуры и удалять ф-ии. Менять сигнатуру нельзя. С оверлоадами вообще ад.


С плагинами никаких проблем нет - можно сделать либо новый интерфейс, к-ый поддерживается тем же манагером, либо унаследовать новый от старого (если старое АПИ надо расширить, а не заменить).

Как это не будет. Очень даже будет. Если брать мой пример, с подсвечиванием элемента, где рисуется рамочка изменение поведения этого подсвечивания в самой Qt приведёт к тому, что опять мне эту рамочку нужно будет копипастить. Да и вообще, её же для меня нету (этой функции), её воообще могут убрать и придумать совершенно другое.


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

Ничего разработчики менять не будут и не собираются. Они прекрасно сами это видят и ничего менять не хотят.

Не будет. Публичное API останется таким же. Еще раз - рамки станут рисоваться ПО РАЗНОМУ, но код продолжит работать и будет делать то, что делал раньше (старый вариант).

Должен быть известен размер структуры, передается в параметрах или записан в самой структуре. Callback(и) (плагин зовет хост) имеют ID команды. Оба (плагин и хост) возвращают код ошибки. Вот собственно и все. Расширять - без проблем. Остальное (менять поля и.т.п) - ну так это недостижимо, не стоит к этому стремиться.

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

Как-то не звучит чему же это посвящено. Не так уж поздно наступает момент когда все плагины надо перекомпилить/переписать. Портирование на 64 бит, до этого на Intel Mac, на Carbon, на PPC - всякий раз ВЕСЬ софт нужно было обновить. И всякий раз "портирование" совсем не было "просто перекомпилить". В общем это неизбежно, "бинарная совместимость" не спасает. А раз так то и нечего ее раздувать  :)

Без бинарной совместимости ЛЮБОЕ обновление ОС (читай - линукса с кедами) ломало бы весь софт. Никто (кроме гентушников) не будет пересобирать полоперационки при каждом обновлении Qt. Почему вы пыаетесь применять практики, возможные в приложении на библиотечный код? Я кстати давно заметил, что почти никто не умеет писать библиотеки общего пользования.

Про линукс с кедами ничего не знаю, но на Mac именно так и было - да, ломался ВЕСЬ софт. Пару лет давали попастись на "эмуляторе" (нар Розетта), а потом "с приветом".

Ну и зачем мне это уметь? И что есть "библиотека общего пользования"? Вот хотя бы либа FBX, общего ли она пользования? По-народному да, многие приложения ее пользуют. И бинарная совместимость там очень простая - все идет в namespace имя которого = номер версии. Вот файлы да, и сверху вниз и наоборот. А это - зачем? Нужны новые фичи/подформаты, ну так обновляйтесь. Совместимось приложение-плагины решается куда более простыми средствами. Поэтому да, мне это кажется преувеличенным и раздутым, не знаю ни одного примера где это актуально.   

Это не любое обновление. Qt тоже ломает совместимость раз в Н лет между мажорными релизами. А теперь представьте, что вам ВЕСЬ софт надо пересобирать\переставлять КАЖДУЮ НЕДЕЛЮ

Что самое интересное, так и происходит.

Но вы так и не рассказали, как сосущесвует этот мир. Возьмём Windows, в виду её закрытости легче рассуждать. Как дружат с бинарниками почти с десяток компилятров. Опять же, если вы обладаете знаниями в этой теме, прошу поделиться. У меня их к примеру нету. Отбросим COM интерфейсы, с ними всё понятно.

Хотя, сдаётся мне, просто там не присутствуют плюсы в виде доступного айпи.

Я не знаю, что у вас там происходит, когда мне приходит  обновление Qt на линуксе, у меня не обновляются кеды, к-ые от них зависят. Когда приходит обновление фреймворков на маке, не обновляются программы, которые от них зависят.

Давайте возьмем виндовз - программы, собранные в ХР отлично работают в 7ке. Если бы не было бинарной совместимости kernel32.dll хрен бы вы что запустили.

Ну вы уж так сразу категорично. Qt же мы сами исключили из данного опуса, т.к. у них с бинарной совместимостью всё ок.
Я же специально на windows переключился, а там постоянно что либо да обновляется.
Тогда вопрос более конкретный, раз затронули kernel32. Вы хотите сказать что он со времён Windows 3.1 не менялся?

Конечно менялся. Но за всё это время бинарная совместимость не была нарушена.

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

Ладно, тупик.
Но как уживаются разные компиляторы на одной системе. Так уж у них стандартазирована vmt?. Если так, то почему на линухе смена компилятора не тривиальная задача.

Не знаю, никогда не вызывал ф-ии винапи по имени:)

На линухе компиляторы отлично уживаются - шланг с гцц можно мешать как душе угодно. Причем не очень понимаю, почему вы разговор о совместимости версий библиотек переводите разговор на совместимость ABI. Разве что, вы не понимаете что есть что:)

Это потому что за вас "привязку" сделали - описали прототипы, уже молчу даже про паскалевский тип вызова.

Ааааа. Вы не поняли, что я имел в виду. По имени в виде строки.


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

Во первых, действительно не понимаю, как разные компиляторы уживаются друг с другом (что вы назвали ABI).
Во вторых, не понял, что вы имеете в виду под "шланг с gcc".
И в третих нить треда потерялась, скоро спутники начнём запускать.

Но для себя я определённые выводы сделал.

С чего начиналось - есть функция, которая копируется внутри самих исходников Qt. На вопрос почему вы уже ответили: "Не время её сейчас выпячивать, чтобы ничего не ломать" либо "А ну его, так проще, чтобы ничего не ломать."

Это потому что за вас "привязку" сделали - описали прототипы, уже молчу даже про паскалевский тип вызова.

О.... Вы не поняли, что я имел в виду. По имени в виде строки.


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

Во первых, действительно не понимаю, как разные компиляторы уживаются друг с другом (что вы назвали ABI).
Во вторых, не понял, что вы имеете в виду под "шланг с gcc".
И в третих нить треда потерялась, скоро спутники начнём запускать.

Но для себя я определённые выводы сделал.

С чего начиналось - есть функция, которая копируется внутри самих исходников Qt. На вопрос почему вы уже ответили: "Не время её сейчас выпячивать, чтобы ничего не ломать" либо "А ну его, так проще, чтобы ничего не ломать."

Кто сделал привязку? О чем вы вообще? Это просто 2 разных способа работы с библиотекой - динамическая загрузка или линковка. В обоих способах либа предоставляет набор экспортируемых функций, как их вызывать - ваше дело.


0) Вместо кернела возьмите любую системную библиотеку:) Для вашего удобства я взял известную вам либу, а не CoreFoundation.framework какой-нибудь:)
1) шланг = clang, яблочный компилятор.
2) Начну издалека.
Есть формат бинарника - это то, как располагаются секции кода\данных в исполняемом файле, формат заголовков и тому подобное. Как правило, на каждой операционке свой формат - в винде .exe, в линупсе ELF, на маке - mach-o.

Есть архитектура бинарника - один и тот же формат подерживает разные архитектуры (какая разница, какие чиселки лежат в секции кода)

Есть ABI - это высокоуровневое понятие, связанное с тем, как именовать экспортируемые ф-ии в библиотеке и как передавать параметры. Для си ABI относительно стандартизовано - имя экспортируемой ф-ии не меняется, передача параметров регулируется пачкой макросов (вы можете указать компилятору как звать ту или иную библиотечную функцию). Поэтому extern "C" функции отлично понимают любые компиляторы.
Для с++ ABI не стандартизовано. Например, нет стандарта на именование экспортируемой ф-ии (как правило, это XXXNamespaceXXXClassXXXParam1XXX где ХХХ - это какой-то непонятный набор символов, у всех компиляторов разный). Или то, где размещать vtable (обычно, она лежит первым членом класса, но вот борланд размещает ее ПЕРЕД классом). Соответственно, есть понятие "ABI компилятора X" - это ABI, к-ый является "родным" для компилера X. В линуксе/маке основным является ABI gcc, поэтому, для совместимости, clang также использует это ABI (и полностью совместим с gcc). На венде основным является ABI msvc, но у него есть проблема - это ABI разный для разный версий комилятора. По этой причине (а на самом деле просто не осилили) остальные компиляторы юзают своё ABI, не совместимое с msvc (речь про плюсы, как я говорил, си стандартизовано) - у mingw gcc'шное ABI. Аналогично clang под вендой - по умолчанию использует ABI gcc; вместе с тем, работы по эмуляции ABI msvc также ведутся, но не очень успешно.

И, наконец, есть понятие Binary Compatibility - это совместимость разных версий одной и той же библиотеки. Если вы можете подменить либу Х версии А на версию А+1 и приложение запустится, это значит, что версия А+1 бинарно совместима с версией А.

Нет, я ответил наоборот - "мы ее сейчас выпятим, а потом окажется, что эта функция не нужна, а удалить ее не сможем". Чтобы что-то выпятить наружу надо понять а) нужно ли это достаточному числу пользователей б) если нужно, то нужно ли это в том виде, в каком оно сейчас в) что будет с этой функцией через 5 лет. Это всё ненулевая работа, которую надо делать. Если у вас есть лишнее время - вперед, займитесь. В Qt действительно много кода, который не помешало бы выпятить. Ради бога, начните только с platform extras:)

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

А с чем же с вами не согласен? Сложна ли Qt в плане разработки? Офигительно! Мы понимамаем, что разработчики не хотят делать резких шагов.  Я могу привести функции которые они заложили и не реализовали (но смотрели вперёд же). Зря вам кажется, что это примитивная вещь (в плане моей функции). Нет, отбросте "одинаковое поведение", тут это не сработает. Могли они на этапе проектирования класса предвидеть это? Могли. Но это очень сложно, запросто могли пропустить.

Тем более,  что работы по "выпячиванию" данной функции внаружу вы оценили уж слишком "затратной" (в плане программирования)

Я не знаю, примитивная ли ваша функция или нет, я не смотрел. Если вам её надо - отправьте патч кутешникам. Если это разумное действие, патч примут и в следующей версии ваша функция будет в паблик API:)

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

В основном - параметры (на каком регистре что), само по себе имя неинтересно. Кстати вот типичная рекомендацияЭто, строго говоря, неверно. Требуется совместимость ABI. И сишные либы ходят без перекомпиляции т.к. эту совместимость имеют. И мудизм debug/release (версии либы) только на Вындоуз.

Все же непонятно каким боком это касается Вас лично. Др словами ну зачем следовать правилам бинарной совместимости в обычном, рабочем коде? Ладно, это Ваше личное дело, в любом случае спасибо за подробные объяснения.

Я уже ответил - если вы клепаете формочки (а вы, очевидно, клепаете), то незачм. Если у вас регулярно появляются наработки, которые можно использовать в других разрабатываемых приложениях (у нас их десятки, но они маленькие), то придётся крутиться.

:)