Breeze: Perché non è disponibile di default in KDE 5?

Come già sappiamo, KDE Next (o KDE 5 come preferisci) è stato rilasciato come stabile pochi giorni fa e tra le nuove funzionalità che porta, una delle più chiacchierate è il nuovo Artwork chiamato Breeze.

Brezza

Chi ha già provato questa nuova versione o ha visto il video, potrebbe aver notato che nel caso del decoratore di finestre, quello che viene fornito di default è Oxygen e non Breeze. Anche Martin Grasslin ci spiega sul tuo blog qual è il motivo di questa decisione.

Poiché l'articolo è in inglese, cercherò di portarvi l'idea fondamentale di questo.

Perché Breeze non viene fornito di default?

Inizio con la spiegazione di come funzionano le decorazioni delle finestre in KWin 4. KWin è il cosiddetto re-genitorialità dei gestori di finestre. Ciò significa che la finestra gestita da X11 viene inserita in un'altra finestra X11 che fornisce il frame della finestra. In KWin usiamo QWidget per il telaio della finestra. Pertanto siamo anche limitati a ciò che QWidget ci fornisce ... La nostra soluzione è intercettare tutti gli eventi di pittura decorativa in QWidget e sopprimerli, attivare un ridipingere del compositore e nella fase di rendering garantire la decorazione di un'immagine temporanea che poi viene copiato in una texture.


La decorazione della finestra del tema Breeze si basa sul motore del tema Aurorae. Dato che sono l'autore principale di Aurorae, posso raggiungerlo in questo post del blog senza sentirmi a disagio 🙂 Aurorae è stato progettato per creare facilmente una decorazione e utilizzare le nuove funzionalità di traslucenza. Essendo una soluzione che potrebbe essere utilizzata come decorazione di default, ma non è mai stato il loro obiettivo. L'idea era di consentire agli utenti che desiderano la personalizzazione di questa funzione, mentre la maggior parte degli utenti può utilizzare temi nativi più veloci. Aurorae non è mai stata veloce e non sarà veloce.


Ora in KWin 5, l'uso di QML è il problema principale che rende difficile l'uso di Aurorae. QtQuick utilizza Scenegraph e utilizza QWindows invece di QWidget. È un peccato per la nostra API basata su QWidget. Abbiamo adattato l'utilizzo interno per supportare le decorazioni basate su QWindows, ma è stata una strada piuttosto difficile, poiché ci sono differenze nel comportamento delle finestre. Poiché non è più basato su QWidget, il trapping degli eventi di pittura è interrotto e avevamo bisogno di una nuova soluzione. E questa soluzione è ancora più brutta della precedente perché QtQuick sta attualmente lavorando tramite OpenGL. A causa delle limitazioni nell'applicazione OpenGL Qt (potrebbe essere risolto in Qt 5.4) che non possiamo condividere con il contesto OpenGL usato da QtQuick ... Questo non è solo un enorme sovraccarico quando si copia il contenuto dalla GPU alla RAM e viceversa alla GPU, stai anche sprecando molta memoria. Nel caso di una finestra ingrandita, non è solo la barra del titolo, ma l'intera finestra. E c'è quell'overhead per ogni finestra.


Questo da solo può rendere Aurorae totalmente inutilizzabile. Attualmente sto utilizzando il tema Breeze e KWin ha bisogno di più di 200 MB di RAM - non proprio accettabile. Ma la situazione è anche peggiore. Con QWindows non possiamo sapere quali aree sono state aggiornate. Quindi, quando, ad esempio, un pulsante viene aggiornato, dobbiamo ridipingere l'intera finestra, inclusa la copia completa del contenuto della decorazione. Questo soprattutto nelle situazioni di animazione è un grosso problema.


Allora qual è la via da seguire? Ho iniziato a implementare una nuova decorazione per l'API rimuovendo la restrizione sulla decorazione basata sul benessere di QWidget e allo stesso tempo ho iniziato a implementare la decorazione Breeze con questa nuova API. Spero di poterlo introdurre in KWin 5.1.


Ed è così che stanno le cose, signori. Spero che tu capisca più o meno qual è il problema. Chiederò a Martin se non è più pratico e veloce creare il tema nativo di Breeze come Oxygen, anche se al momento non sono preoccupato, Oxygen sebbene non sia la cosa più carina del mondo, ha molte opzioni ..


Lascia un tuo commento

L'indirizzo email non verrà pubblicato. I campi obbligatori sono contrassegnati con *

*

*

  1. Responsabile dei dati: Miguel Ángel Gatón
  2. Scopo dei dati: controllo SPAM, gestione commenti.
  3. Legittimazione: il tuo consenso
  4. Comunicazione dei dati: I dati non saranno oggetto di comunicazione a terzi se non per obbligo di legge.
  5. Archiviazione dati: database ospitato da Occentus Networks (UE)
  6. Diritti: in qualsiasi momento puoi limitare, recuperare ed eliminare le tue informazioni.

  1.   ivanbarra suddetto

    Ho letto tutto, ma non ho capito niente, oggi sono lento. Ad ogni modo, non riesco ancora a testare KDE 5 sul mio OpenSUSE 13.1. Mi rompe a causa di alcune "vecchie" dipendenze che ho.
    Forse ti darò un'altra possibilità con un altro sistema operativo virtuale.

    Saluti e grazie per l'input.

    1.    nano suddetto

      Non è facile, in fondo cerca di spiegare che il modo di fare le implementazioni è complesso, soprattutto per i plugin e che, in sostanza aurorae è SLOW, molto più di Oxygen.

      Non so, in questo senso, nella parte del decoratore di finestre e tutto ciò che mi sembra tale

    2.    nano suddetto

      Non è facile, in fondo cerca di spiegare che il modo di fare le implementazioni è complesso, soprattutto per i plugin e che, in sostanza aurorae è SLOW, molto più di Oxygen.

      Non so, in questo senso, nella parte del decoratore di finestre e tutto ciò che mi sembra che KDE sia un passo dietro GNOME, e attenzione, sono un fan di KDE al massimo, solo che non è difficile per me ammettere qualcosa quando è vero.

    3.    Txarran suddetto

      Senza sapere nulla sull'argomento, quello che ho sostanzialmente capito è che aurorae (il motore che usa Breeze) ora dà problemi perché Kwin5 non usa più qwidget come in kwin4 e le finestre non si comportano allo stesso modo. Utilizza invece QML e QTquick che funzionano direttamente con opengl e quindi sembra che alcune limitazioni esistenti in qt 5.3 impediscano al vecchio motore e ai suoi temi di non funzionare bene nel nuovo Kwin.

  2.   mat1986 suddetto

    Sarebbe possibile creare (o adattare) Breeze allo stile o al modo di lavorare di Oxygen?

  3.   andekuera suddetto

    Qualcuno ha idea di cosa succederà a qtcurve?

    1.    Txarran suddetto

      Qtcurve-qt5 funziona perfettamente da un po 'di tempo. La nuova versione di KDE seguirà come sempre.

      1.    aiolia suddetto

        Era già strano per me che a Kaos, che è sempre in prima linea nel presente, testare Kf5 quindi è noto che in Kaos linux plasma next o kde 5 l'ossigeno sarebbe arrivato per impostazione predefinita. Wow, non sapevi di essere il creatore di Aurorae ...

        1.    Txarran suddetto

          Sono il creatore delle aurore? O_o;

  4.   Sergio E. Duran suddetto

    Stavo creando un sostituto per breeze anche in aurorae chiamato next fresh che in seguito sarebbe stato breeze fresh ma non posso con l'adattamento degli SVG al tema quindi il suo sviluppo è inattivo, elav se hai l'opportunità mi piacerebbe che tu glielo mostrassi. creatore del tema breeze per vedere se possono portare l'idea della mia decorazione aurorae alle decorazioni native di KDE come alternativa alla decorazione breeze

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

  5.   eliotime3000 suddetto

    Penso che KDE 5 sarà su Fedora, Debian, Slackware e Arch quando avrò famiglia e figli e avrò circa 30 anni.

    Insomma, per continuare a sfruttare la piccola giovinezza che mi è rimasta.