Breeze: De ce nu vine în mod implicit în KDE 5?

După cum știm deja, KDE Next (sau KDE 5 după cum preferați) a fost lansat la fel de stabil acum câteva zile și printre noile caracteristici pe care le aduce, una dintre cele mai discutate este noua lucrare de artă numită Breeze.

Briză

Cei care au încercat deja această nouă versiune sau au văzut videoclipul, poate au observat că în cazul decoratorului de ferestre, cel care vine în mod implicit este Oxigen și nu Breeze. De asemenea Martin Grasslin ne explică pe blogul său care este motivul acestei decizii.

Deoarece articolul este în limba engleză, voi încerca să vă aduc ideea fundamentală a acestui lucru.

De ce Breeze nu vine în mod implicit?

Încep cu explicația modului în care funcționează decorațiunile ferestrelor în KWin 4. KWin este așa-numita re-parenting a managerilor de ferestre. Aceasta înseamnă că fereastra gestionată de X11 este introdusă într-o altă fereastră X11 care oferă cadrul ferestrei. La KWin folosim QWidget pentru cadrul ferestrei. Prin urmare, suntem, de asemenea, limitați la ceea ce QWidget ne oferă ... Soluția noastră este să interceptăm toate evenimentele de pictură a decorațiilor din QWidget și să le suprimăm, să declanșăm o revopsire a compozitorului și în etapa de redare să garantăm decorarea unei imagini temporare care apoi este copiat într-o textură.


Decorarea ferestrei temei Breeze se bazează pe motorul tematic Aurorae. Întrucât sunt autorul principal al Aurorae, îl pot accesa pe această postare de pe blog, fără să mă simt rău în legătură cu asta. Fiind o soluție care ar putea fi folosită ca decor implicit, dar nu a fost niciodată scopul lor. Ideea a fost de a permite utilizatorilor care doresc personalizarea acestei caracteristici, în timp ce majoritatea utilizatorilor pot utiliza teme native care sunt mai rapide. Aurora nu a fost niciodată rapidă și nu va fi rapidă.


Acum, în KWin 5, utilizarea QML este principala problemă care face ca Aurorae să fie dificil de utilizat. QtQuick folosește Scenegraph și folosește QWindows în loc de QWidget. Aceasta este o problemă pentru API-ul nostru bazat pe QWidget. Am ajustat utilizarea internă pentru a accepta decorațiile bazate pe QWindows, dar acesta a fost un drum destul de dificil, deoarece există diferențe în comportamentul ferestrelor. Deoarece nu se mai bazează pe QWidget, blocarea evenimentelor noastre de vopsea este ruptă și aveam nevoie de o nouă soluție pentru aceasta. Și această soluție este chiar mai urâtă decât cea anterioară, deoarece QtQuick lucrează în prezent prin OpenGL. Datorită limitării aplicației OpenGL Qt (ar putea fi abordată în Qt 5.4) pe care nu o putem împărtăși cu contextul OpenGL folosit de QtQuick ... Aceasta nu este doar o cheltuială imensă atunci când copiezi conținutul de pe GPU pe RAM și înapoi la GPU, de asemenea pierdeți multă memorie. În cazul unei ferestre maximizate nu este doar bara de titlu, ci întreaga fereastră. Și există această cheltuială pentru fiecare fereastră.


Numai asta poate face Aurorae total inutilizabile. În prezent folosesc tema Breeze și KWin are nevoie de mai mult de 200 MB de memorie RAM - nu chiar acceptabil. Dar situația este și mai gravă. Cu QWindows nu putem ști ce zone au fost actualizate. Deci, atunci când, de exemplu, un buton este actualizat, trebuie să revopsim întreaga fereastră, inclusiv copia completă a conținutului decorului. Că mai ales în situații de animație este o mare problemă.


Deci, care este calea de urmat? Am început să implementez o nouă decorație pentru API prin eliminarea restricției privind decorarea bazată pe bunăstare a QWidget și, în același timp, am început să implementez decorația Breeze cu acest nou API. Sper că putem introduce acest lucru în KWin 5.1.


Și așa stau lucrurile, domnilor. Sper să înțelegeți mai mult sau mai puțin care este problema. Îl voi întreba pe Martin dacă nu este mai practic și mai rapid să creez tema Breeze nativă, cum ar fi Oxigenul, deși în acest moment nu sunt îngrijorat, Oxigenul, deși nu este cel mai drăguț lucru din lume, are o mulțime de opțiuni ..


11 comentarii, lasă-le pe ale tale

Lasă comentariul tău

Adresa ta de email nu va fi publicată. Câmpurile obligatorii sunt marcate cu *

*

*

  1. Responsabil pentru date: Miguel Ángel Gatón
  2. Scopul datelor: Control SPAM, gestionarea comentariilor.
  3. Legitimare: consimțământul dvs.
  4. Comunicarea datelor: datele nu vor fi comunicate terților decât prin obligație legală.
  5. Stocarea datelor: bază de date găzduită de Occentus Networks (UE)
  6. Drepturi: în orice moment vă puteți limita, recupera și șterge informațiile.

  1.   ivanbarram el a spus

    Am citit totul, dar nu am înțeles nimic, astăzi sunt lent. Oricum, încă nu pot testa KDE 5 pe OpenSUSE 13.1. Mă rupe din cauza unor dependențe „vechi” pe care le am.
    Poate vă voi oferi o altă șansă cu un alt sistem de operare într-unul virtual.

    Salutări și mulțumiri pentru contribuție.

    1.    nano el a spus

      Nu este ușor, practic încearcă să explice că modul de realizare a implementărilor este complex, în special pentru plugin-uri și că, în esență, aurorele sunt LENTE, mult mai mult decât Oxigenul.

      Nu știu, în acest sens, în partea decoratorului de ferestre și tot ce mi se pare asta

    2.    nano el a spus

      Nu este ușor, practic încearcă să explice că modul de realizare a implementărilor este complex, în special pentru plugin-uri și că, în esență, aurorele sunt LENTE, mult mai mult decât Oxigenul.

      Nu știu, în acest sens, în partea decoratorului de ferestre și tot ce mi se pare că KDE este un pas în spatele GNOME și, ferește-te, sunt un fan al KDE la maximum, doar că nu este dificil să admit ceva când este adevărat.

    3.    Txarran el a spus

      Fără să știu nimic despre subiect, ceea ce am înțeles practic este că aurorele (motorul pe care Breeze îl folosește) oferă acum probleme deoarece Kwin5 nu mai folosește qwidget ca în kwin4 și ferestrele nu se comportă la fel. În schimb, folosește QML și QTquick care funcționează direct cu opengl și, prin urmare, se pare că unele limitări existente în qt 5.3 împiedică vechiul motor și temele sale să nu funcționeze bine în noul Kwin.

  2.   mat1986 el a spus

    Ar fi fezabil să creăm (sau să adaptăm) Breeze la stilul sau modul de lucru pe care îl are oxigenul?

  3.   Ñandekuera el a spus

    Oricine are idee ce se va întâmpla cu qtcurve?

    1.    Txarran el a spus

      Qtcurve-qt5 funcționează perfect de ceva timp. Noua versiune a KDE va ​​urma ca întotdeauna.

      1.    aiolia el a spus

        Mi-a fost deja ciudat faptul că în Kaos, care este întotdeauna în fruntea prezentului, testarea Kf5, deci se știe în Kaos linux plasma next sau kde 5 oxigenul ar veni în mod implicit. Uau, nu știai că ești creatorul Aurorei ...

        1.    Txarran el a spus

          Sunt creatorul aurorelor? O_o;

  4.   Sergio E. Duran el a spus

    Am creat un înlocuitor pentru briza, de asemenea, în aurore numite next fresh, care mai târziu ar fi briza proaspătă, dar nu pot cu adaptarea SVG-urilor la temă, astfel încât dezvoltarea sa este inactivă, elav, dacă aveți ocazia, mi-ar plăcea să vi-l arăt. creator al temei briza pentru a vedea dacă pot transporta ideea decorării aurorelor mele la decorațiunile native KDE ca alternativă la decorarea brizei

    https://drive.google.com/file/d/0B6VUkpZzqL7hbk1QbWN6eVcycU0/edit?usp=sharing

  5.   eliotime3000 el a spus

    Cred că KDE 5 va fi pe Fedora, Debian, Slackware și Arch când voi avea familie și copii și voi avea aproximativ 30 de ani.

    Pe scurt, să profitez în continuare de micul tineret care mi-a rămas.