Los desarrolladores del sistema de diseño de PCB de código abierto KiCad han informado sobre el estado de implementación de la compatibilidad con Wayland y han resumido los problemas que impiden el uso completo de este protocolo. Se recomienda a los usuarios que diseñan PCB profesionalmente en KiCad o que desean obtener un entorno estable y completamente funcional que ejecuten KiCad en entornos de escritorio basados en X11, como Xfce, MATE o la sesión X11 de KDE Plasma.
Quienes pretendan usar KiCad en entornos Wayland deben estar preparados para posibles bloqueos y fallos, la imposibilidad de restaurar la disposición de ventanas deseada y una funcionalidad de interfaz limitada. Se dice que estas limitaciones se deben a la falta de características en Wayland que se han utilizado durante mucho tiempo en aplicaciones X11. Windows и macOS, como por ejemplo la compatibilidad con el posicionamiento de ventanas y el movimiento instantáneo del puntero del ratón (desplazamiento del cursor).
En cuanto a los fallos que se producen, están asociados a una gran fragmentación del material compuesto. servidores Para Wayland. GNOME, KDE y los gestores de composición individuales interpretan los protocolos de Wayland de forma diferente, lo que dificulta confiar en una implementación única y consistente de los protocolos de Wayland y las extensiones experimentales durante el desarrollo. Los desarrolladores de aplicaciones deben tener en cuenta las particularidades de cada entorno y emplear soluciones alternativas para abordar los problemas específicos de los distintos gestores de composición.
La fragmentación de los servidores de composición aumenta significativamente el esfuerzo necesario para implementar la compatibilidad con Wayland. Lo más frustrante es que los desarrolladores de KiCad no pueden solucionar los problemas por sí mismos, ya que estos no son inherentes a KiCad, sino a los protocolos, los gestores de ventanas y los servicios de composición. servidores.
Dado que Linux Dado que solo un pequeño porcentaje de usuarios de KiCad lo utiliza, se decidió evitar añadir soluciones alternativas a problemas específicos del gestor de ventanas al código del proyecto, continuando con el desarrollo de KiCad para Wayland y probando la compatibilidad de las versiones. Todos los problemas y limitaciones identificados se documentarán y se comunicarán a los usuarios.
El rastreador de errores ha decidido no abordar las quejas de los usuarios de Wayland relacionadas con el posicionamiento y el tamaño de las ventanas, la configuración del foco, así como bloqueos, fallas, aumento de la carga de la CPU, problemas con los dispositivos de entrada y fallas de renderizado que no aparecen en la compilación X11.
Entre los problemas conocidos que están fuera del control de los desarrolladores de KiCad y que no se pueden resolver en el lado de KiCad se encuentran:
- Problemas con la gestión de ventanas: Imposibilidad de controlar la posición de ventanas y paneles (al abrir KiCad, no se puede recordar ni restaurar la posición de ventanas y barras de herramientas). Problemas para coordinar el trabajo con varias ventanas simultáneamente. Capacidad limitada para mover pestañas y paneles entre diferentes áreas.
- Problemas con los dispositivos de entrada: La deformación del cursor depende de extensiones de protocolo experimentales opcionales, compatibles solo con algunos gestores de composición. Comportamiento impredecible al gestionar el foco de entrada. Problemas con dispositivos de entrada especializados y el manejo de atajos de teclado.
- Problemas de estabilidad y rendimiento: Mayor consumo de recursos y carga de CPU/GPU en comparación con X11. Artefactos gráficos durante el renderizado que interrumpen la salida normal. Bloqueos y fallos que solo ocurren al ejecutarse en entornos basados en Wayland. Manejo poco fiable del portapapeles.
- Limitaciones de la interfaz de usuario: Problemas con el posicionamiento, el enfoque y la interacción en los diálogos modales. Problemas con el inicio y la gestión de aplicaciones externas.
Además, se observan avances en el desarrollo del proyecto X11Libre, que desarrolla la bifurcación de X.Org Server. En los 10 días transcurridos desde su fundación, 11 participantes se han unido al desarrollo y han enviado 31 cambios. Enrico Weigelt, autor de la bifurcación, transfirió 1267 de sus cambios a la bifurcación, que no fueron aceptados en la versión principal de X.Org. Mientras tanto, los desarrolladores de X.Org revirtieron 6 cambios del código base de X.Org Server, previamente aceptados por Enrico Weigelt, lo que provocó regresiones o el marcado de algunas funciones como obsoletas (en total, se aceptaron 1568 cambios en X.Org Server antes de que Enrico creara la bifurcación).
Kevin Kofler del proyecto Fedora, que forma parte del grupo de trabajo que mantiene los paquetes KDE, propuso reemplazar Fedora Linux El paquete xorg-x11-xserver será reemplazado por la implementación del servidor X de la bifurcación XLibre. El motivo declarado para el reemplazo es migrar a una base de código con un mantenimiento más activo, en lugar de seguir distribuyendo el proyecto X.Org, obsoleto y con escasas actualizaciones, que, según sus desarrolladores, prácticamente no recibe mantenimiento. El autor de la bifurcación fue el colaborador más activo del proyecto X.Org Server, y su distribución beneficiará a los creadores de ediciones de Fedora que aún utilizan X11, por ejemplo, gracias a la incorporación de la extensión Xnamespace X11 a X11Libre, que proporciona aislamiento de cliente a nivel de espacio de nombres X11. La propuesta aún no ha sido aprobada por FESCo (Fedora Engineering Steering Committee), responsable del desarrollo técnico de la distribución Fedora.
Fuente: opennet.ru
