"Закрытость" Qt

[Авварон]

Ну, её можно было бы засунуть в static protected метод класса QGraphicsItem, тем более что она не использует данные класса, пользователь данной функции ничего бы поломать не смог.

Нельзя.

[AzazelloAV]

Ну, её можно было бы засунуть в static protected метод класса QGraphicsItem, тем более что она не использует данные класса, пользователь данной функции ничего бы поломать не смог.

Нельзя.

Можно.

[Igors]

По поводу qt_graphicsItem_highlightSelected

Ну, её можно было бы засунуть в static protected метод класса QGraphicsItem, тем более что она не использует данные класса, пользователь данной функции ничего бы поломать не смог.

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

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

Теперь по поводу ctreateItemGroup

Я, если честно, не понял вашего решения с groupClass (придется самому, скопировать из исходников и заменить new). Да, это понятно, но извените, топик как раз и называется - закрытость Qt, это ли не показатель закрытости?

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

Код

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

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

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

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

[AzazelloAV]

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

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

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

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

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

[Авварон]

должны быть виртуальны

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

[Igors]

Вы же говорите примитивные, пусть даже правильные вещи - смирись, изучи всё досконально, полазь по исходникам вдоль и поперёк, а там уже сможешь!

Совершенно верно, именно так

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

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

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

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

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

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

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

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

[AzazelloAV]

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

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

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

[Авварон]

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

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

Код:

class C 
{
    virtual int getValue() const {...};
    virtual void setValue(int value) {...}
};

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

Код:

class QAbstractItemView
{
    QAbstractItemModel *model() const;
    virtual void setModel(QAbstractItemModel *model) {..}
};

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

Код:

class AbstractDocument
{
    QUrl url() const {...}
    void setUrl(QUrl url) { _url = url; open(url); }

protected:
   virtual bool open(QUrl url) = 0;
};

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

Код:

class Command
{
    QString text();
    void setText(QString);
};

class CommandPrivate
{
    virtual setText(QString) {...}
};

class Action : public Command
{
// в паблик API ничего не добавилось и не поменялось
};

class ActionPrivate
{
   void setText(QString text) { qAction->setText(text); }
};

class Menu : public Command
{
};

class MenuPrivate
{
   void setText(QString text) { qMenu->setText(text); }
};

[Igors]

Код:

    void setText(QString);

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

Код:

Пример три (еще лучше, NVI)
class AbstractDocument
{
    QUrl url() const {...}
    void setUrl(QUrl url) { _url = url; open(url); }

protected:
   virtual bool open(QUrl url) = 0;
};

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

Спасибо

[Авварон]

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

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

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

Спасибо

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

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

[Igors]

Если вам аргумент про бинарную совместимость кажется надуманным, ...

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

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

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

[kuzulis]

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

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

[AzazelloAV]

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

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

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

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

[Igors]

Такой же таск намбер ту (простой как 2 копейки) ...
...такой же  примитивный 2-й

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

[AzazelloAV]

Такой же таск намбер ту (простой как 2 копейки) ...
...такой же  примитивный 2-й

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

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

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

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