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

[Igors]

Не может быть две простые вещи - "покрасить в зеленый цвет и повернуть направо" отличаться временем разработки на порядки (в десятичной системе)

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

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

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

[AzazelloAV]

Не может быть две простые вещи - "покрасить в зеленый цвет и повернуть направо" отличаться временем разработки на порядки (в десятичной системе)

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

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

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

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

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

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

[Igors]

Мысль проста - а был бы метод protected virtual QListWidgetItem::selectedView подсвечивания этого самого итема, насколько бы проще было бы вам и мне и самое главное, насколько это было бы красивое решение.

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

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

Код

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

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

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

[Авварон]

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

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

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

Вот тут Саттер рассматривает примеры и говорит обратное, но вне привязки к оптимизации. При этом он говорит, что в конструктор лучше передавать копию, так как мы и так будем копировать.

[Авварон]

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

Код

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

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

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

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

[AzazelloAV]

Мысль проста - а был бы метод protected virtual QListWidgetItem::selectedView подсвечивания этого самого итема, насколько бы проще было бы вам и мне и самое главное, насколько это было бы красивое решение.

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

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

Код

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

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

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

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

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

[Igors]

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

Все равно считать пр-ки надо самому, рамку самому и текст - тоже самому. Последнее оказалось тоже непросто, см здесь. Выходит со стандартного/стилед делегата я ничего не поимел (а xотелось бы).

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

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

Давайте все-все-все виртуал - и будет счастье, Qt откроется!! А то сейчас виртуалов мало, все закрыто"

ну пока это все что я понял из Вашей аргументации 

[AzazelloAV]

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

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

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

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

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

[Авварон]

Все равно считать пр-ки надо самому, рамку самому и текст - тоже самому. Последнее оказалось тоже непросто, см здесь. Выходит со стандартного/стилед делегата я ничего не поимел (а xотелось бы).

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

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

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

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

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

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

[AzazelloAV]

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

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

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

Но тут есть одна засада на ваш вопрос.

Вы хотите, чтобы ваш код ломался при переходе на новую версию Qt?

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

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

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

[Igors]

Вы видели где нибудь private virtual метод? Нет, т.к. это бессмысленно.

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

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

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

Это шо такое? Текст рисуй, иконку рисуй, размеры считай. Почему мне не дали все готовое? Да откуда я знаю "как", что вы мне глупые вопросы задаете? Это их дело, а мне надо 2 строки написать - и все готово

[Авварон]

Но тут есть одна засада на ваш вопрос.

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

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

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

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

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

[Igors]

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

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

Ой, Вань, а не высоко ль ты мостисся?

Правильно ли я понимаю?

[Авварон]

А вот С API не имеет ни одной такой злополучной проблемы 

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

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

Ой, Вань, а не высоко ль ты мостисся?

Правильно ли я понимаю?

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

[AzazelloAV]

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

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

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

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

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

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