Comme nous le savons déjà, KDE Next (ou KDE 5 comme vous préférez) est sorti il y a quelques jours comme stable et parmi les nouvelles fonctionnalités qu'il apporte, l'une des plus discutées est la nouvelle Artwork appelée Breeze.
Ceux qui ont déjà essayé cette nouvelle version ou qui ont vu la vidéo, ont peut-être remarqué que dans le cas du décorateur de fenêtres, celui qui vient par défaut est Oxygen et non Breeze. Aussi Martin Gräßlin nous explique sur votre blog quelle est la raison de cette décision.
Comme l'article est en anglais, je vais essayer de vous en apporter l'idée fondamentale.
Pourquoi Breeze n'est-il pas proposé par défaut?
Je commence par expliquer le fonctionnement des décorations de fenêtres dans KWin 4. KWin est ce qu'on appelle la re-parentalité des gestionnaires de fenêtres. Cela signifie que la fenêtre gérée par X11 est placée dans une autre fenêtre X11 qui fournit le cadre de la fenêtre. Chez KWin, nous utilisons QWidget pour le cadre de la fenêtre. Par conséquent, nous sommes également limités à ce que nous offre QWidget ... Notre solution est d'intercepter tous les événements de peinture de décoration dans QWidget et de le supprimer, de déclencher un repeint du compositeur et dans l'étape de rendu garantir la décoration d'une image temporaire qui ensuite est copié dans une texture.
La décoration de la fenêtre du thème Breeze est basée sur le moteur de thème Aurorae. Comme je suis l'auteur principal d'Aurorae, je peux le consulter sur ce billet de blog sans me sentir mal à ce sujet 🙂 Aurorae a été conçu pour être très facile à créer une décoration et à utiliser les nouvelles fonctionnalités de translucidité. Être une solution qui pourrait être utilisée comme décoration par défaut, mais cela n'a jamais été leur but. L'idée était de permettre aux utilisateurs souhaitant personnaliser cette fonctionnalité, alors que la plupart des utilisateurs peuvent utiliser des thèmes natifs plus rapides. Aurorae n'a jamais été rapide et elle ne le sera pas.
Désormais dans KWin 5, l'utilisation de QML est le principal problème qui rend l'utilisation d'Aurorae difficile. QtQuick utilise le Scenegraph et utilise QWindows au lieu de QWidget. C'est une déception pour notre API basée sur QWidget. Nous avons ajusté l'utilisation interne pour prendre en charge les décorations basées sur QWindows, mais c'était une route assez difficile, car il existe des différences dans le comportement des fenêtres. Comme il n'est plus basé sur QWidget, notre trappage d'événements de peinture est cassé et nous avions besoin d'une nouvelle solution pour cela. Et cette solution est encore plus moche que la précédente car QtQuick travaille actuellement via OpenGL. En raison des limitations de l'application OpenGL Qt (qui pourraient être traitées dans Qt 5.4) que nous ne pouvons pas partager avec le contexte OpenGL utilisé par QtQuick ... Ce n'est pas seulement une surcharge énorme lors de la copie du contenu du GPU vers la RAM et vice versa au GPU, vous gaspillez également beaucoup de mémoire. Dans le cas d'une fenêtre agrandie, ce n'est pas seulement la barre de titre, mais la fenêtre entière. Et il y a cette surcharge pour chaque fenêtre.
Cela seul peut rendre Aurorae totalement inutilisable. J'utilise actuellement le thème Breeze et KWin a besoin de plus de 200 Mo de RAM - pas vraiment acceptable. Mais la situation est encore pire. Avec QWindows, nous ne pouvons pas savoir quelles zones ont été mises à jour. Ainsi, lorsque, par exemple, un bouton est mis à jour, nous devons repeindre toute la fenêtre, y compris la copie complète du contenu de la décoration. Cela, surtout dans les situations d'animation, est un gros problème.
Alors, quelle est la voie à suivre? J'ai commencé à implémenter une nouvelle décoration pour l'API en supprimant la restriction sur la décoration basée sur le bien-être de QWidget et en même temps j'ai commencé à implémenter la décoration Breeze avec cette nouvelle API. J'espère que nous pouvons introduire cela dans KWin 5.1.
Et c'est ainsi que les choses sont, messieurs. J'espère que vous comprenez plus ou moins quel est le problème. Je vais demander à Martin s'il n'est pas plus pratique et plus rapide de créer le thème Breeze natif comme Oxygen, même si pour le moment je ne suis pas inquiet, Oxygen bien que ce ne soit pas la chose la plus mignonne au monde, il a beaucoup d'options ...
J'ai tout lu, mais je n'ai rien compris, je suis lent aujourd'hui. Quoi qu'il en soit, je ne peux toujours pas tester KDE 5 sur mon OpenSUSE 13.1. Cela me brise à cause de certaines "vieilles" dépendances que j'ai.
Peut-être que je vais vous donner une autre chance avec un autre système d'exploitation virtuel.
Salutations et merci pour votre contribution.
Ce n'est pas facile, il essaie essentiellement d'expliquer que la manière de faire les implémentations est complexe, surtout pour les plugins et que, par essence, les aurores sont LENTES, bien plus que Oxygen.
Je ne sais pas, en ce sens, dans le rôle du décorateur de fenêtres et tout ce qui me semble que
Ce n'est pas facile, il essaie essentiellement d'expliquer que la manière de faire les implémentations est complexe, surtout pour les plugins et que, par essence, les aurores sont LENTES, bien plus que Oxygen.
Je ne sais pas, en ce sens, dans la partie du décorateur de fenêtres et tout ce qui me semble que KDE est un pas en arrière de GNOME, et attention, je suis fan de KDE au maximum, seulement qu'il ne m'est pas difficile d'admettre quelque chose quand c'est vrai.
Sans rien savoir sur le sujet, ce que j'ai essentiellement compris, c'est que les aurores (le moteur utilisé par Breeze) posent désormais des problèmes car Kwin5 n'utilise plus qwidget comme dans kwin4 et les fenêtres ne se comportent pas de la même manière. Au lieu de cela, il utilise QML et QTquick qui fonctionnent directement avec opengl et il semble donc que certaines limitations existantes dans qt 5.3 empêchent l'ancien moteur et ses thèmes de ne pas fonctionner correctement dans le nouveau Kwin.
Serait-il possible de créer (ou d'adapter) Breeze au style ou à la façon de travailler d'Oxygen?
Quelqu'un a une idée de ce qui va arriver à qtcurve?
Qtcurve-qt5 fonctionne parfaitement depuis un certain temps. La nouvelle version de KDE suivra comme toujours.
C'était déjà étrange pour moi qu'à Kaos, qui est toujours à la pointe du présent, tester Kf5 donc il est connu dans Kaos linux plasma next ou kde 5 oxygène viendrait par défaut. Wow, vous ne saviez pas que vous étiez le créateur d'Aurorae ...
Je suis le créateur des aurores? O_o;
J'étais en train de créer un remplaçant pour Breeze également dans les aurores, appelé next fresh qui serait plus tard frais, mais je ne peux pas avec l'adaptation des SVG au thème donc son développement est inactif, elav si vous en avez l'occasion j'aimerais que vous le lui montriez. créateur du thème Breeze pour voir s'ils peuvent porter l'idée de ma décoration aurore aux décorations natives de KDE comme alternative à la décoration brise
https://drive.google.com/file/d/0B6VUkpZzqL7hbk1QbWN6eVcycU0/edit?usp=sharing
Je pense que KDE 5 sera sur Fedora, Debian, Slackware et Arch quand j'aurai de la famille et des enfants et que j'aurai environ 30 ans.
Bref, pour continuer à profiter de la petite jeunesse qui me reste.