Breeze: Per què no ve per defecte en el KDE 5 €

Com ja sabem KDE Next (o KDE 5 com a prefereixin) va ser llançat com estable fa alguns dies i entre les novetats que porta amb si, una de les més comentades és el nou Artwork anomenat Breeze.

Brisa

Els que ja han provat aquesta nova versió o han vist el vídeo, s'hauran pogut adonar que en el cas de l'decorador de finestres, el que ve per defecte és Oxygen i no Breeze. doncs bé Martin Gräßlin ens explica al seu bloc quin és el motiu d'aquesta decisió.

Com l'article està en anglès, intentaré portar-los a vostès la idea fonamental d'això.

Per que Breeze no ve per defecte?

Començo amb l'explicació de com funcionen les decoracions de les finestres en KWin 4. KWin és l'anomenat re-parenting dels gestors de finestres. Això significa que la finestra gestionada per X11 es posa a part X11 que proporciona el marc de la finestra. En KWin utilitzem QWidget per al marc de la finestra. Per tant nosaltres també estem restringits al QWidget ens proporciona ... La nostra solució és interceptar tots els esdeveniments de pintura de la decoració en QWidget i suprimir-lo, desencadenar un repintat de el compositor i en el pas de representació garantir els decoració d'una imatge temporal que després es copia en una textura.


La decoració de la finestra del tema Breeze es basa en el motor del tema Aurorae. Com jo sóc l'autor principal de Aurorae puc copejar-ho en aquesta entrada de bloc sense sentir-me malament per això 🙂 Aurorae va ser dissenyat perquè sigui molt fàcil de crear una decoració i fer ús de les noves característiques de translucidesa. Sent una solució que podria ser utilitzat com a decoració per defecte, però mai va ser el seu objectiu. La idea era permetre als usuaris que desitgen la personalització aquesta funció, mentre que la majoria dels usuaris pot utilitzar els temes nadius que són més ràpids. Aurorae mai va ser ràpid i no serà ràpid.


Ara en KWin 5, l'ús de QML és el principal problema que fa que sigui difícil d'usar Aurorae. QtQuick utilitza el Scenegraph i utilitza QWindows en lloc de QWidget. Això és una nosa per a la nostra API basada QWidget. Ajustem l'ús intern per donar suport decoracions basades en QWindows, però això va ser tot un camí difícil, ja que hi ha diferències en el comportament de les finestres. Com que ja no es basa en QWidget, la nostra intercepció d'esdeveniments de pintura es trenca i necessitàvem una nova solució per a això. I aquesta solució és encara més lletja que l'anterior perquè QtQuick està actualment funcionant a través d'OpenGL. A causa de les limitacions en l'aplicació OpenGL Qt (podrien ser abordats en Qt 5.4) que no podem compartir amb el context OpenGL utilitzat per QtQuick ... Això no només és una enorme sobrecàrrega a l'copiar el contingut de la GPU a la memòria RAM i de nou a la GPU, també està perdent una gran quantitat de memòria. En cas d'una finestra maximitzada no és només la barra de títol, però la finestra completa. I hi ha aquesta sobrecàrrega per a cada finestra.


Això per si sol pot fer Aurorae totalment inutilitzable. Actualment estic fent servir el tema Breeze i KWin necessita de més de 200 MB de RAM - no és realment acceptable. Però la situació és encara pitjor. Amb QWindows no aconseguim saber quines àrees van aconseguir actualitzar-se. Així que quan, per exemple, un botó s'actualitza hem de tornar a pintar la finestra completa, incloent la còpia completa de l'contingut de la decoració. Que sobretot en situacions d'animació és un gran problema.


Llavors quin és el camí a seguir? Vaig començar a implementar una nova decoració per a la API eliminant la restricció de la decoració basat en el benestar de QWidget i a el mateix temps vaig començar a implementar la decoració d'Breeze amb aquesta nova API. Espero que puguem introduir això en KWin 5.1.


I així són les coses senyors. Espero que s'entengui més o menys com és el problema. Vaig a preguntar-li a Martin si no és més pràctic i ràpid fer el tema de Breeze natiu a l'igual que Oxygen, encara que de moment a mi no em preocupa, Oxygen encara que no és el més bonic de l'món, té un munt d'opcions ..


Deixa el teu comentari

La seva adreça de correu electrònic no es publicarà. Els camps obligatoris estan marcats amb *

*

*

  1. Responsable de les dades: Miguel Ángel Gatón
  2. Finalitat de les dades: Controlar l'SPAM, gestió de comentaris.
  3. Legitimació: El teu consentiment
  4. Comunicació de les dades: No es comunicaran les dades a tercers excepte per obligació legal.
  5. Emmagatzematge de les dades: Base de dades allotjada en Occentus Networks (UE)
  6. Drets: En qualsevol moment pots limitar, recuperar i esborrar la teva informació.

  1.   ivanbarram va dir

    Vaig llegir tot, però no vaig entendre res, camino lent avui. De tota manera, encara no m'és possible provar KDE 5 en mi OpenSUSE 13.1. Es em trenca per algunes dependències «velles» que tinc.
    Potser li d'una altra oportunitat amb un altre SO en alguna virtual.

    Salutacions i Gràcies per l'entrada.

    1.    nano va dir

      És que no és senzill, bàsicament tracta d'explicar que la manera de fer les implementacions és complexa, sobretot pels plugins i que, en essència aurorae és LENT, molt més que Oxygen.

      No ho sé, en aquest sentit, en la part de l'decorador de finestres i tot això em sembla q

    2.    nano va dir

      És que no és senzill, bàsicament tracta d'explicar que la manera de fer les implementacions és complexa, sobretot pels plugins i que, en essència aurorae és LENT, molt més que Oxygen.

      No ho sé, en aquest sentit, en la part de l'decorador de finestres i tot això em sembla que el KDE està un pas enrere del GNOME, i ull, jo sóc un fan del KDE a mes no poder, només que no em costa admetre alguna cosa quan és cert.

    3.    Txarran va dir

      Sense saber res del tema del que jo he entès bàsicament és que aurorae (el motor que fa servir Breeze) ara dóna problemes perquè Kwin5 ja no utilitza qwidget com a kwin4 i les finestres no es comporten igual. En el seu lloc utilitza QML i QTquick que funciona directament amb opengl i per això sembla que algunes limitacions existents en qt 5.3 impedeixen que el vell motor i els temes d'aquest no rendeixin bé en el nou KWin.

  2.   mat1986 va dir

    Seria factible crear (o adaptar) Breeze a l'estil o manera de funcionar que té Oxygen?

  3.   Ñandekuera va dir

    Algú té idea què passarà amb qtcurve?

    1.    Txarran va dir

      Qtcurve-qt5 funciona perfectament des de fa força temps. Va a seguir com sempre la nova versió del KDE.

      1.    Aioria va dir

        Ja se m'ha cap estrany que en Kaos, que sempre està a l'avantguarda de l'actual provant Kf5 així es coneix en Kaos linux plasma next o kde 5 vingués oxygen per defecte. Vaja no sabies que eres el creador d'aurorae ...

        1.    Txarran va dir

          Jo sóc el creador d'aurorae? O_o;

  4.   Sergio E. Durán va dir

    Jo estava creant un reemplaçament de breeze també en aurorae anomenat next fresh el qual després seria breeze fresh però no puc amb l'adaptacion dels SVGs a el tema pel que aquesta inactiu el seu desenvolupament, ILAV si tens l'oportunitat m'encantaria que l'hi mostressis a l' creador del tema breeze per veure si poden traslladar la idea de la meva decoració de aurorae a les decoracions natives del KDE com una alternativa a la decoració breeze

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

  5.   eliotime3000 va dir

    Crec que el KDE 5 estarà en Fedora, Debian, Slackware i Arch quan tingui família i fills, i voregi els 30 anys.

    En fi, a seguir aprofitant la poca joventut que em queda.