Бриз: Защо не идва по подразбиране в KDE 5?

Както вече знаем, KDE Next (или KDE 5, както предпочитате) беше пуснат като стабилен преди няколко дни и сред новите функции, които носи, една от най-обсъжданите е новата Artwork, наречена Breeze.

Тези, които вече са изпробвали тази нова версия или са видели видеоклипа, може да са забелязали, че в случая с декоратора на прозорци този, който идва по подразбиране, е кислород, а не бриз. Както добре Martin Gräßlin ни обяснява в неговия блог каква е причината за това решение.

Тъй като статията е на английски, ще се опитам да ви представя основната идея на това.

Защо Breeze не идва по подразбиране?

Започвам с обяснението как работят декорациите на прозорци в KWin 4. KWin е така нареченото повторно родителство на мениджърите на прозорци. Това означава, че управляваният с X11 прозорец се поставя в друг прозорец на X11, който осигурява рамката на прозореца. В KWin използваме QWidget за рамката на прозореца. Следователно ние също сме ограничени до това, което ни предоставя QWidget ... Нашето решение е да прихванем всички събития за рисуване на декорации в QWidget и да го потиснем, да задействаме пребоядисване на композитора и в стъпката за изобразяване да гарантираме декорацията на временно изображение, което след това се копира в текстура.

Декорацията на прозореца на тема Breeze се основава на тематичния двигател на Aurorae. Тъй като аз съм водещият автор на Aurorae, мога да го засегна в тази публикация в блога, без да се чувствам зле за него 🙂 Aurorae е проектиран да бъде много лесен за създаване на декорация и използване на новите функции за полупрозрачност. Като решение, което може да се използва като декорация по подразбиране, но никога не е било тяхната цел. Идеята беше да се позволи на потребителите, които искат персонализиране на тази функция, докато повечето потребители могат да използват естествени теми, които са по-бързи. Аврорите никога не са били бързи и няма да бъдат бързи.

Сега в KWin 5 използването на QML е основният проблем, който прави Aurorae труден за използване. QtQuick използва Scenegraph и използва QWindows вместо QWidget. Това е неприятно за нашия API, базиран на QWidget. Променихме вътрешната употреба, за да поддържаме базирани на QWindows декорации, но това беше доста труден път, тъй като има разлики в поведението на прозореца. Тъй като вече не се основава на QWidget, нашето улавяне на събития за боя е прекъснато и имахме нужда от ново решение за него. И това решение е дори по-грозно от предишното, защото QtQuick в момента работи чрез OpenGL. Поради ограничения в приложението OpenGL Qt (може да се обърне внимание в Qt 5.4), които не можем да споделим с контекста на OpenGL, използван от QtQuick ... Това е не само огромни разходи при копиране на съдържанието от графичния процесор в RAM и обратно към GPU, вие също губите много памет. В случай на максимизиран прозорец това е не само заглавната лента, но и целият прозорец. И има такива режийни за всеки прозорец.

Само това може да направи Аврорите напълно неизползваеми. В момента използвам темата Breeze и KWin се нуждае от повече от 200MB RAM - не е наистина приемливо. Но ситуацията е още по-лоша. С QWindows не можем да знаем кои области са актуализирани. Така че, когато например се актуализира бутон, трябва да пребоядисаме целия прозорец, включително пълното копие на съдържанието на декорацията. Това особено в анимационни ситуации е голям проблем.

И така, какъв е пътят напред? Започнах да внедрявам нова декорация за API, като премахнах ограничението върху декорацията на QWidget, базирана на благосъстоянието, и в същото време започнах да прилагам декорацията Breeze с този нов API. Надявам се, че можем да представим това в KWin 5.1.

И нещата стоят така, господа. Надявам се горе-долу да разберете какъв е проблемът. Ще попитам Мартин дали не е по-практично и по-бързо да се направи родната тема Breeze като Oxygen, макар че в момента не се притеснявам, Oxygen, въпреки че не е най-сладкото нещо на света, има много настроики ..