Портирование рисования

[Bepec]

https://drive.google.com/file/d/0B_mrvcleB88yZTVJMU9oLTlNYjg/edit?usp=sharing
С фильтрами мудрить не стал, нет времени на отладку, но мысль ясна я думаю.

[Igors]

https://drive.google.com/file/d/0B_mrvcleB88yZTVJMU9oLTlNYjg/edit?usp=sharing
С фильтрами мудрить не стал, нет времени на отладку, но мысль ясна я думаю.

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

- нужно следить чтобы он пропускал события через себя
- нужно следить чтобы он был все время самым верхним и покрывал все (напр при resize)
- нужно его зачищать а когда?
и.т.д.

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

Мое мнение - в данном случае надо подходить более принципиально/идейно. Рисование double-buffered, (пусть в одном случае средствами ОС, в др средствами Qt) - значит и надо рисовать прямо в буфере, если такая необходимость возникла. И неважно что там в букваре пишут. А пытаться решить это еще одним (triple) буфером - безыдейно и обречено на "ловлю блох" ("костыль" в молодежных терминах)

Ну ничего, ответили кодом - уже молодец 

[Bepec]

Кхм...

в данном случае это явно не к месту

1) Рисование "поверх" подразумевает наличие нескольких слоёв для контроля, собственно, рисования. Думаю вы лучше меня это знаете.

- нужно следить чтобы он пропускал события через себя

2) Достаточно модифицировать пример из Шлее или Бланшета (не помню точно у кого) для пропуска сообщений. Этот функционал я не сделал, ибо его нужно отлаживать, а времени не особо было.

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

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

- нужно его зачищать а когда?

4) Зачищать когда хотите. Ибо вы получаете полную власть над слоем. Что угодно, хоть чёртиков рисуйте, хоть ангелов стирайте.

напр инвертировать участок окна Вы не сможете.

5) Могу. У меня есть картинка родителя. И у меня есть холст для рисования поверх. Далее уже дело техники.
Получить картинку, инвертировать цвета и нарисовать поверх - спокойно. Придётся часто обновлять в зависимости от области. Но это будет уже затратно и стоит задуматься "а оно нам надо?" ©.
В общем реализуемо, но малополезно.

более принципиально/идейно.

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

И по той же цитате.

7) Мы хотим рисовать под виджетом (сам виджет), на виджете (контролы) и над виджетом (поверхность). По здравому смыслу надо всё разделять, что мы и делаем, как благоразумные программисты.
3 сущности, как вы правильно и заметили. Мы же не дикари всё пихать в одну котомку.

Задача выполнена? Да. (возразите?)
Затратно? Нет.
Получили ещё один класс? Ради этого тема и была создана. Та малая толика, что он съест компенсируется выполнением задачи.

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

Там предлагался ещё способ, я к сожалению не помню какой. Других способов "контролируемого" рисования поверх виджета пока нет.

PS кстати идейный подход вас не смущает смешиванием сущностей?

PPS ваш способ кстати использует хедеры Qt 5.* . Так что я пока не видел примера работающего кода.

[Igors]

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

Пример как это работает

Код

C++ (Qt)
OldPainter painter(window);
Rect R = GetControlRect(comboBox);
for (int i = 0; i < 100; ++i) {
 DoSomething(i);
 painter.FillRect(&R, i);
}
Inval(&R);
 

Операция идет, прогресс виден - комбик последовательно заливается каким-то цветом. Сам комбик об этом без понятия - это может быть любой др контрол - или область окна. Хорошо, прилетело какое-то чужое окно, а потом скрылось - ну так на след итерации буфер окна опять отфлашится в видео, все норм. Вот все 100 итерации завершены, ушли на цикл событий, а там уже ждет paint который просто отрисует комбик - без всякой заливки которая уже не нужна.

[Bepec]

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

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

PS было интересно ^.^

[kamre]

Вот все 100 итерации завершены, ушли на цикл событий, а там уже ждет paint который просто отрисует комбик - без всякой заливки которая уже не нужна.

А как во время итераций обрабатываются остальные события вроде нажатия на кнопку отмены текущей операции?

[Igors]

Ваш пример будет работать только при итеративной отрисовке с быстрыми "тиками", я так понимаю.

Этот пример да, а вообще не только. Часто встречается ситуевина когда операция модальна/монопольна, напр юзверь схватил объект и тащит. Перерисовываться надо, но вот др события не должны извлекаться из очереди пока мыша не отпущена.

А как во время итераций обрабатываются остальные события вроде нажатия на кнопку отмены текущей операции?

Этого никто не отменял, и об этом я создал др топик  
http://www.prog.org.ru/index.php?topic=26251.msg187843#msg187843

[Old]

Часто встречается ситуевина когда операция модальна/монопольна, напр юзверь схватил объект и тащит. Перерисовываться надо, но вот др события не должны извлекаться из очереди пока мыша не отпущена.

Ох уж эти обобщения... "Часто встречается"... У кого часто встречается? Кому это надо?
Посмотрите как реализован DnD в том же Qt, там нет таких странных ограничений.
С какой стати сообщения не должны извлекаться и обрабатываться?

[Bepec]

Old, прошу вас, остановитесь Тема уже почти почти завершена

[Old]

Old, прошу вас, остановитесь Тема уже почти почти завершена

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

[Igors]

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

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

[Old]

"нам" - за всех не расписывайтесь

А вы пишете для кого-то конкретно? Указывайте это, иначе вы пишете нам всем.

Есть портируемое приложение которое делает вещи так, и наивно думать что все будет "так же как в Qt".

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

[Bepec]

Не буду холиварить, но поддержу Old.
Ибо если один у нас ходит кверх ногами, это не повод всех переучивать в принудительном порядке. Проще прописать этому "одному" лечебных процедур.

PS вы всегда можете скрыть реализацию от приложения. И только вы будете знать как жутко вы обманываете бедную и беззащитную программу.

[Igors]

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

Ну вот Вы уже и грубите А что же плохого делает приложение? Конечно, рисовать так необязательно, но что в этом некорректного/неграмотного? Я лично ничего не нашел, в обоих используемых ОС это 100% легально. Хорошо, давайте "переделаем по Qt-шному", но никаких Ваших предложений я не видел. Чего ж теперь Вы жопу вспомнили? 

[Old]

А что же плохого делает приложение?

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

Хорошо, давайте "переделаем по Qt-шному", но никаких Ваших предложений я не видел.

Никакого "Qt-шного" нет, это штатное рисование для большинства (если не всех) платформ.
Или на маках не нужно обрабатывать сообщение типа paintEvent?