В GTK+ 3.12 обнаружена серьёзная проблема с декорациями окон

О чём речь-то?

О необходимости твоего посещения окулиста. Очевидно же.

Таким постом, думаю, разработчики плеера намекают о том, что они устали гоняться за прогрессом, за конкурентными плеерами, и уже не мешало бы закрыть проект, так как на переписывать на qt не ни сил не желания, и что уже даже нет сил, - «хотим на пенсию» ноют))

Например как в Elementary.

В елементари 3.5 приложения, остальное там как и в обычном пролетарском линуксе. Чем это от гнома/кде отличается?

GLUI, Cluter…

4.2. Система рисует заголовок только в случае зависания приложения, и это костыль. Штатно рисует приложение, и все радовались до XP тому, как весело было, когда приложение зависает. http://blogs.msdn.com/b/oldnewthing/archive/2006/03/27/561924.aspx

Я одного не понял.

В gnome 3.10 используется мешанина приложений с client side декорациями и обычными. При этом в сторонних WM все работает как надо: где есть клиентские декорации, там штатные не рисуются. В 3.12 это что, сломали не глядя?

ну а я о чем?

Рекомендую срочно посетить психиатра, есть шанс, что ещё не поздно.

почему люди не используют «чистые» openGL'ные оконные библиотеки? Нафига эти костыли и подпорки?

у opengl есть свои проблемы, особенно в линупсе. например, с драйверами. нагрузка на видеокарту и проц, опять же, типично выше с opengl, отсюда нагрев. готовых нормальных виджет тулкитов, опять же, нет (только в составе разных приложений, типа blender). но попробуй запустить тот же блендер на компе с vesa дровами. простое -lGL добавляет ~20Mb расхода оперативы к процессу. под композитными WM, отрисовка через GL в разы тормознее 2д графики через те же cairo/xrender.

GLUI

Рипнулось ещё в 2006-м году...

GLUI, Cluter…

истории успеха есть?

Очень просто: сколько раз уже Qt из рук в руки кочевал? Не выгоден он. Проприетарщины на этом тулките мало пишут, а опенсорс ни копейки не заплатит. Потому рано или поздно Qt купит серьёзная фирма, связанная с разработкой ПО, а таких сейчас мало - M$ и Apple с Samsung. Другим оно вообще не надо. Apple Qt будет только для MacOSX и оффтопика пилить, притом под мак сильнее, чтоб был повод себя пиарить, а M$ просто закопает, ибо нефиг без VisualStudio программы писать, да ещё кроссплатформенные.

Проприетарщины на этом тулките мало пишут

ORLY? Уже 5-й проект сдаю.

нагрузка на видеокарту и проц, опять же, типично выше с opengl

Что за бред? OpenGL с блобом — это кайф! Да даже интеловские недовидюхи уже умеют такое.

на компе с vesa дровами

Бугага.

Если что-то буду гуевое пилить, то стопудово никаких GTK, Qt и прочего говна. В худшем случае — motif. Но хочу таки OpenGL.

А от GTK уже блевать тянет: мало того, что GTK2 близится к стадии "deprecated", так оно уже превратилось в жутчайший быдлокод с офигенными тормозами. Зачем мне такая гуебиблиотека?

Почему-то в кедах планируют рисовать декорации KWin'ом.

Потому что «в кедах» умные люди, и они понимают — декорации лучше рисовать серверу, поэтому пишут соответствующий копмозитор. А референсный weston требует csd, gnome-shell (и mutter) тоже всю дорогу писали с прицелом на csd и уже успели наговорить гору лажи и зомбировать свою армию фанатиков.

4.2. Система рисует заголовок только в случае зависания приложения, и это костыль.

4.2. По-умолчанию декорации рисует система, а приложение — только содержимое. Приложение может влиять на процесс, может даже попросить не добавлять декорации, а самостоятельно управлять всем, включая видимую форму окна по маске прозрачности. Если такое приложение перестало обрабатывать очередь сообщений, ему на время принудительно нарисуют рамку и постараются запомнить содержимое окна. Именно об этом по твоей ссылке.

Но основная мякотка Fvwm - очень гибкая настройка

Йавкурсе.

слабо завязана на xorg

Тем не менее, оно скриптуется поверх примитивов ксорга.

Так что если скрещивать fvwm с weston, то надо отрисовку взять из weston, а определение, что отрисовывать из fvwm

Это на словах так всё просто, а на практике придётся чуть ли не всё переписывать. Учитывая его довольно малую аудиторию (тот же awesome по возможностям уже почти догнал FVWM, и вообще последний популярен в основном среди вымирающих олдфагов), если и взлетит, то ещё очень не скоро.

И настанет JavaFX-рай.

так есть же weston. объединить его с fvwm возможно будет проще

В смысле «написать плагин для weston, имитирующий какие-то из фич fvwm»? Может, и проще. Но в wayland некоторые вещи фундаментально отличаются by design: например, последнее слово в определении размера окна — за окном, оно выдаёт буфер WxH точек и ставит перед фактом, что его нужно отрисовать. Композитор может разве что зумить его (юзер этого вряд ли ожидает).

Совсем обкурились.

в общем если бы да ка бы

Что за бред? OpenGL с блобом — это кайф! Да даже интеловские недовидюхи уже умеют такое.

это факты, я лично проверял, именно с блобом (невидия).

Хреново ты проверял. OpenGL тем и хорош, что процессор практически не напрягается, видеокарта всей подноготной занимается.

OpenGL тем и хорош, что процессор практически не напрягается

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

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

зы: я это не очень понятно, или совсем непонятно, написал в оригинальном сообщении, но большая нагрузка на CPU в оконных (GUI) opengl приложениях типично происходит не по вине самих приложений, а из-за наличия запущенного композитного WM. если композитинг отключить - все ок, CPU% в норме. но всем юзверям не отключишь.

из-за наличия запущенного композитного WM

ССЗБ могут и дырки в цилиндрах движка просверлить, а потом удивляться: а чего это оно не едет?

ССЗБ могут и дырки в цилиндрах движка просверлить, а потом удивляться: а чего это оно не едет?

тут как раз ситуация такая, что им движок уже выдали с просверленными цилиндрами.

А куда он смотрел, когда покупал? И в любом случае, если лыжи не едут по асфальту, то надо выбирать варианты...

А куда он смотрел, когда покупал? И в любом случае, если лыжи не едут по асфальту, то надо выбирать варианты...

ну это стандартная проблема. но вот по этим причинам, гуй на opengl популярность набирать никак не хочет. девелоперы не хотят рисковать. если 100% аудитории сидит на композитных WM — заставить их с них слезть не получится, и получать 100500 багрепортов «ваше приложение тормозит!!!111» тоже никто не хочет.

Client-side decorations — это идиотизм.

тут как раз ситуация такая, что им движок уже выдали с просверленными цилиндрами.

Композитный WM уже тем хорош, что избавляет от тиринга.

Чудесный гвоздь в крышку гроба гытыка.

Любое приложение из состава GNU априори лучше его аналогов.

Этому не наливать.

По-умолчанию декорации рисует система

Nope, main loop приложения должен работать и проигнорировать WM_NCPAINT (ну или обработать его, одна фигня), чтобы нарисовалась дефолтная рамка.

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

Это появилось только начиная с Vista, и это, собственно, и есть костыль.

о переводе плеера Audacious на другой тулкит (возможно это будет Qt)

Нееееет! Зачем нам еще один qmmp?

нагрузка на видеокарту и проц, опять же, типично выше с opengl, отсюда нагрев.

Нагрев чего и до скольки градусов по Цельсию ?

Нееееет! Зачем нам еще один qmmp?

Бабушка, успокойтесь, Джонни только думает над этим.

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

Спасибо, теперь понятно. OpenGL не умеет в видеокарту напрямую...

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

В венде можно перехватить событие отрисовки «рамочки» и нарисовать на ней что угодно из приложения. Сам так делал, когда кастомные кнопки\надписи нужны были на рамке.