Como ya sabemos KDE Next (o KDE 5 como prefieran) fue lanzado como estable hace algunos días y entre las novedades que trae consigo, una de las más comentadas es el nuevo Artwork llamado Breeze.
Los que ya han probado esta nueva versión o han visto el video, se habrán podido percatar de que en el caso del decorador de ventanas, el que viene por defecto es Oxygen y no Breeze. Pues bien Martin Gräßlin nos explica en su blog cual es el motivo de esta decisión.
Como el artículo está en Inglés, trataré de llevarles a ustedes la idea fundamental de esto.
¿Por que Breeze no viene por defecto?
Empiezo con la explicación de cómo funcionan las decoraciones de las ventanas en KWin 4. KWin es el llamado re-parenting de los gestores de ventanas. Esto significa que la ventana gestionada por X11 se pone en otra ventana X11 que proporciona el marco de la ventana. En KWin utilizamos QWidget para el marco de la ventana. Por lo tanto nosotros también estamos restringidos a lo QWidget nos proporciona… Nuestra solución es interceptar todos los eventos de pintura de la decoración en QWidget y suprimirlo, desencadenar un repintado del compositor y en el paso de representación garantizar los decoración de una imagen temporal que luego se copia en una textura.
La decoración de la ventana del tema Breeze se basa en el motor del tema Aurorae. Como yo soy el autor principal de Aurorae puedo golpearlo en esta entrada del blog sin sentirme mal por ello 🙂 Aurorae fue diseñado para que sea muy fácil de crear una decoración y hacer uso de las nuevas características de translucidez. Siendo una solución que podría ser utilizado como decoración por defecto, pero nunca fue su objetivo. La idea era permitir a los usuarios que desean la personalización esta función, mientras que la mayoría de los usuarios puede utilizar los temas nativos que son más rápidos. Aurorae nunca fue rápido y no será rápido.
Ahora en KWin 5, el uso de QML es el principal problema que hace que sea difícil de usar Aurorae. QtQuick utiliza el Scenegraph y utiliza QWindows en lugar de QWidget. Eso es un fastidio para nuestra API basada QWidget. Ajustamos el uso interno para apoyar decoraciones basadas en QWindows, pero eso fue todo un camino difícil, ya que hay diferencias en el comportamiento de las ventanas. Como ya no se basa en QWidget, nuestra interceptación de eventos de pintura se rompe y necesitábamos una nueva solución para ello. Y esta solución es aún más fea que la anterior porque QtQuick está actualmente funcionando a través de OpenGL. Debido a las limitaciones en la aplicación OpenGL Qt (podrían ser abordados en Qt 5.4) que no podemos compartir con el contexto OpenGL utilizado por QtQuick… Esto no sólo es una enorme sobrecarga al copiar el contenido de la GPU a la memoria RAM y de nuevo a la GPU, también está perdiendo una gran cantidad de memoria. En caso de una ventana maximizada no es sólo la barra de título, pero la ventana completa. Y existe esa sobrecarga para cada ventana.
Eso por sí solo puede hacer Aurorae totalmente inutilizable. Actualmente estoy usando el tema Breeze y KWin necesita de más de 200 MB de RAM – no es realmente aceptable. Pero la situación es aún peor. Con QWindows no conseguimos saber qué áreas consiguieron actualizarse. Así que cuando, por ejemplo, un botón se actualiza tenemos que volver a pintar la ventana completa, incluyendo la copia completa del contenido de la decoración. Que sobre todo en situaciones de animación es un gran problema.
¿Entonces cuál es el camino a seguir? Empecé a implementar una nueva decoración para el API eliminando la restricción de la decoración basado en el bienestar de QWidget y al mismo tiempo empecé a implementar la decoración de Breeze con esta nueva API. Espero que podamos introducir esto en KWin 5.1.
Y así son las cosas señores. Espero que se entienda más o menos cual es el problema. Voy a preguntarle a Martin si no es más práctico y rápido hacer el tema de Breeze nativo al igual que Oxygen, aunque de momento a mi no me preocupa, Oxygen aunque no es lo más lindo del mundo, tiene un montón de opciones..
Leí todo, pero no entendí nada, ando lento hoy. De todas maneras, aún no me es posible probar KDE 5 en mi OpenSUSE 13.1. Se me rompe por algunas dependencias «viejas» que tengo.
Quizá le de otra oportunidad con otro S.O. en alguna virtual.
Saludos y Gracias por la entrada.
Es que no es sencillo, básicamente trata de explicar que la manera de hacer las implementaciones es compleja, sobre todo por los plugins y que, en esencia aurorae es LENTO, mucho más que Oxygen.
No lo sé, en este sentido, en la parte del decorador de ventanas y todo eso me parece q
Es que no es sencillo, básicamente trata de explicar que la manera de hacer las implementaciones es compleja, sobre todo por los plugins y que, en esencia aurorae es LENTO, mucho más que Oxygen.
No lo sé, en este sentido, en la parte del decorador de ventanas y todo eso me parece que KDE está un paso atrás de GNOME, y ojo, yo soy un fan de KDE a mas no poder, solo que no me cuesta admitir algo cuando es cierto.
Sin saber nada del tema lo que yo he entendido basicamente es que aurorae (el motor que usa Breeze) ahora da problemas porque Kwin5 ya no utiliza qwidget como en kwin4 y las ventanas no se comportan igual. En su lugar utiliza QML y QTquick que funciona directamente con opengl y por ello parece que algunas limitaciones existentes en qt 5.3 impiden que el viejo motor y los temas de este no rindan bien en el nuevo Kwin.
¿Sería factible crear (o adaptar) Breeze al estilo o manera de funcionar que tiene Oxygen?
Alguien tiene idea qué va a pasar con qtcurve?
Qtcurve-qt5 funciona perfectamente desde hace bastante tiempo. Va a seguir como siempre la nueva version de KDE.
Ya se me hacia raro que en Kaos, que siempre esta a la vanguardia de lo actual probando Kf5 asi se conoce en Kaos linux plasma next o kde 5 viniera oxygen por defecto. Vaya no sabias que eras el creador de aurorae…
Yo soy el creador de aurorae? O_o;
Yo estaba creando un reemplazo de breeze tambien en aurorae llamado next fresh el cual despues seria breeze fresh pero no puedo con la adaptacion de los SVGs al tema por lo que esta inactivo su desarrollo, elav si tienes la oportunidad me encantaria que se lo mostraras al creador del tema breeze para ver si pueden trasladar la idea de mi decoracion de aurorae a las decoraciones nativas de KDE como una alternativa a la decoracion breeze
https://drive.google.com/file/d/0B6VUkpZzqL7hbk1QbWN6eVcycU0/edit?usp=sharing
Creo que KDE 5 estará en Fedora, Debian, Slackware y Arch cuando tenga familia e hijos, y bordee los 30 años.
En fin, a seguir aprovechando la poca juventud que me queda.