- El equipo de Xfce anunció sus planes para desarrollar un nuevo compositor basado en Wayland,
xfwl4, aprovechando donaciones de la comunidad y con el liderazgo del desarrollador principal Brian Tarricone
- El objetivo es ofrecer las mismas funciones y experiencia de usuario que xfwm4, reutilizando el diálogo de configuración y la configuración de xfconf para asegurar una transición continua
- Estará escrito como código completamente nuevo sobre Rust y el framework smithay, ofreciendo seguridad de memoria y una canalización gráfica y de entrada personalizable
- El alcance del proyecto incluye cambios en la estructura de gestión de sesiones, soporte para XWayland y xdg-session-management, y mejoras al sistema de compilación de CI
- Se trata de una inversión clave para la transición de Xfce a Wayland, y la primera versión de desarrollo está prevista para este año
Plan del nuevo compositor Wayland de Xfce
- El equipo de Xfce comenzó el desarrollo de un nuevo compositor Wayland,
xfwl4, utilizando donaciones de la comunidad
- El desarrollo estará a cargo de Brian Tarricone, colaborador clave de larga trayectoria
- Una parte importante de los fondos del proyecto se destinará a este desarrollo
- El objetivo es implementar en Wayland las mismas funciones y el mismo comportamiento que xfwm4
- Se reutilizarán el diálogo de configuración de xfwm4 y la configuración de xfconf para mantener una experiencia de usuario consistente
- xfwl4 no se basará en el código existente de xfwm4, sino que será reescrito por completo en Rust
- Estará construido sobre la biblioteca smithay
Por qué se decidió reescribir en lugar de reutilizar el código existente
- Al principio se intentó modificar el código de xfwm4 para dar soporte en paralelo a X11 y Wayland, pero se concluyó que no era adecuado por varias razones
- La estructura de xfwm4 es dependiente de X11, lo que dificulta implementar una interfaz generalizada
- Al refactorizar, existe un alto riesgo de introducir errores en X11
- Hay conceptos de X11 que no están soportados en Wayland, lo que complica el mantenimiento del código
- Usar el código existente implicaría depender de C y wlroots
- Desarrollarlo como una base de código separada permite mantener la estabilidad de xfwm4 y avanzar en paralelo con el desarrollo experimental para Wayland
Por qué se eligió smithay
- Brian Tarricone evaluó y comparó wlroots y smithay antes de elegir smithay
- smithay soporta la mayoría de las extensiones oficiales del protocolo Wayland, además de protocolos de wlroots y KDE
- Al no tener abstracciones de alto nivel, permite un control detallado de la canalización gráfica y de entrada
- Cuenta con buena documentación y, al usar Rust, reduce el riesgo de errores de memoria y fallos
- El desarrollador prefiere Rust
- wlroots está escrito en C, por lo que es difícil crear bindings para Rust
Alcance del proyecto y desafíos técnicos
- Además de igualar las funciones de xfwm4, el proyecto incluye las siguientes tareas
- En un entorno Wayland, el compositor debe convertirse en la raíz de la sesión, por lo que es necesario cambiar la estructura de inicio de sesión
- Añadir soporte para el protocolo xdg-session-management
- Incluir soporte para XWayland
- Actualizar el sistema de compilación de contenedores de CI a uno basado en meson que pueda compilar código Rust
- Brian Tarricone ya comenzó el desarrollo y la primera versión de desarrollo está prevista para este año
Comunidad y patrocinio
- El proyecto fue posible gracias a las donaciones de patrocinadores de Open Collective US y EU
- El avance del desarrollo y los detalles técnicos pueden consultarse en los issues de xfwl4 y el repositorio de código fuente en GitLab
- Las consultas relacionadas pueden realizarse a través del canal de Matrix
#xfce-dev
1 comentarios
Comentarios en Hacker News
Había escuchado que xfwl4 apunta a tener la misma funcionalidad y comportamiento que xfwm4
Pero, considerando las diferencias estructurales entre X11 y Wayland, me pregunto qué tan estricta será la interpretación de “comportamiento”
Por ejemplo, la prevención de robo de foco en X11 requiere heurísticas complejas y verificación de marcas de tiempo, pero en Wayland el compositor controla por completo el foco
Al final, existe el reto de diseñar nuevas políticas que encajen con el modelo de permisos de Wayland sin perder la sensación de las heurísticas anteriores
Otro punto de interés es la latencia provocada por forzar el compositing. Me pregunto si en hardware modesto podrá igualar la capacidad de respuesta del modo sin composición de X11
La prevención de robo de foco incluso podría mostrar un comportamiento más consistente en Wayland. Xfwm4 se basaba en heurísticas y a veces fallaba, pero el modelo xdg-activation de Wayland es mucho más claro
En rendimiento, en hardware moderno no parece que vaya a haber gran diferencia, aunque en equipos muy viejos sí podría representar una carga. En la práctica, creo que hará falta probar más
La carga del compositing es básicamente solo el tiempo de espera de vsync. Salvo que sea algo del nivel de un Pentium clásico, debería estar bien
Espero que XFCE siga siendo un escritorio ligero
Me gusta KDE, pero no diría que sea ligero
Veo tanto a Wayland como a Rust de manera positiva; Wayland me parece la dirección del futuro y Rust creo que ayuda a evitar crashes
Aun así, la base tradicional de usuarios de XFCE es conservadora y puede mostrarse escéptica ante nuevas tecnologías
La transición a Wayland es inevitable, y aunque habrá algunas quejas, probablemente avance sin mayores problemas
Los que insisten en X11 al final quedarán como una minoría. Confío en el equipo de XFCE
Ya existe una GUI que funciona bien, y Wayland está creando complejidad innecesaria y problemas de compatibilidad
Los protocolos simples son los que suelen durar, y Wayland va en la dirección contraria
XFCE ya es rápido y estable. Si con el cambio a Wayland se vuelve más lento, estaría perdiendo su mayor ventaja
Como es una comunidad que prioriza la estabilidad, mantendrán X11 como predeterminado y luego pasarán a Wayland cuando haya paridad funcional completa
Espero poder seguir usando XFCE cuando llegue el momento de pasar a Wayland
Creo que este proyecto en sí demuestra que Wayland va en la dirección correcta
Xorg era una implementación única, pero en Wayland han surgido diversos ecosistemas de bibliotecas (wlroots, Smithay, etc.)
Gracias a eso, incluso un proyecto de una sola persona puede sacar una vista previa para desarrolladores en cuestión de meses
Este tipo de competencia hará avanzar al ecosistema open source
Pero ese proceso avanzó con demasiada prisa y le falta integración. Creo que harán falta 10 años más para que exista una API de escritorio Linux realmente completa
Creo que la ausencia de libcompositor fue el mayor error de Wayland
Tengo curiosidad por ver qué resultado entrega el equipo de XFCE
El stack es conveniente, sí, pero al final puede terminar siendo una estructura difícil de modificar en profundidad
X en la práctica funcionaba como un segundo kernel, mientras que Wayland aprovecha abstracciones modernas del kernel como GEM, DMA-BUF y KMS
Gracias a eso puede evolucionar hacia una arquitectura mucho más limpia y eficiente
Llevo más de 10 años usando XFCE como entorno principal
Me alegra la noticia del soporte para Wayland
Si está escrito en Rust, creo que también podría ayudar a atraer colaboradores
Si quieren apoyar el proyecto, recomiendo donar en Open Collective y xfce-eu
Creo que la transición de X11 a Wayland ha sido el cambio más doloroso en la historia de Linux
La época de KDE4 también fue una etapa oscura
He probado el toolkit de cliente en Rust de Smithay, y su seguridad de hilos no es completa
Aunque esté envuelto en Arc<>, aparecen crashes extraños al hacer llamadas multihilo
Me gustaría aprender a usar la API de Wayland de forma directa y segura
Incluso ahora se puede usar XFCE en la mayoría de los compositores basados en wlroots
Yo lo uso en Gentoo con la combinación Hyprland + XFCE
La configuración está en este repositorio
Me da curiosidad por qué describieron la combinación de Hyprland y XFCE4 como una “combinación maldita”. Supongo que quizá tenga relación con la razón por la que XFCE decidió crear su propio compositor
Antes rechazaba Wayland, pero cambié de opinión al ver el rendimiento en hardware antiguo
En un Thinkpad viejo, Firefox hace scroll mucho más suave que en X11
Además se suman los gestos del touchpad, así que estoy satisfecho. La configuración es algo tediosa, pero es un trade-off que vale la pena
Me pregunto si Wayland funciona también en sistemas que no sean Linux. Por ejemplo, ¿en BSD o macOS se pueden mostrar ventanas remotas como con XQuartz?
También existen compositores Wayland para Mac, y Brodie Robertson subió un video al respecto
Si ves el proyecto WSLg, Weston renderiza sobre RDP y eso permite mostrar ventanas entre plataformas
También conserva aceleración por GPU, así que me parece mejor que el reenvío de X11
FreeBSD Handbook Wayland
Hoy en día, cuando escucho “reescritura en Rust”, suelo entender que ya no hay personal para mantenimiento
Parece que están reescribiendo porque no hay quien parchee xfwm4
Eso también puede ser una señal de relevo generacional: nuevos desarrolladores que quieren rehacerlo con una estructura simple y segura
Wayland es más simple que X11 y Rust reduce errores, así que es una evolución natural
Pero el costo puede ser sacrificar transparencia de red, rendimiento y estabilidad. Lo acepto como parte de los tiempos