Una peculiaridad del sistema de ventanas X: ventanas hasta el fondo

Artículo original ↗ Discusión en Hacker News ↗

Las interfaces gráficas desde X11 hasta Microsoft Windows y el clásico Mac OS han tratado durante mucho tiempo casi cualquier elemento en pantalla—botones, cuadros de texto, barras de título—como una especie de “ventana” o vista, cada uno con sus propias coordenadas, eventos y contexto de dibujo. Los comentaristas comparan cómo distintos sistemas implementan esta jerarquía (controles nativos vs “sin ventana”, decoraciones del lado del cliente vs del lado del servidor, límites globales de descriptores y captura de entrada) y cómo esas decisiones afectan al rendimiento, al skinning, a la visualización remota y a la accesibilidad. El tema general es que este modelo de ventanas hasta el fondo es históricamente común y conceptualmente elegante, pero ha tenido que evolucionar o abandonarse en parte a medida que las interfaces se volvieron más ricas y complejas.

Ventana como primitiva universal

  • Muchos sistemas GUI hacen que “todo sea una ventana/vista”: X, Microsoft Windows (HWND), GTK, Qt, las vistas clásicas de Smalltalk y, hasta cierto punto, el clásico Mac (ventanas más controles de menor peso).
  • Los desarrolladores señalan que esto a menudo “surge de forma natural” al implementar una GUI: todo tiene posición, límites, dibujo e hijos, así que “ventanas hasta el fondo” es una arquitectura común, no algo exclusivo de X.
  • Algunos defienden separar conceptos (por ejemplo, ventanas frente a controles) aunque compartan implementación, para mantener más limpio el modelo mental.

Rendimiento, recursos y controles sin ventana

  • Los sistemas antiguos usaban muchas ventanas reales para los controles sin grandes problemas de rendimiento, pero alcanzaban límites de recursos (montones GDI/USER de 16 bits, máximos de descriptores).
  • A medida que las interfaces se hicieron más ricas (navegadores, aplicaciones con skins, transparencia, imágenes complejas), las ventanas por control se volvieron demasiado pesadas; esto motivó los “controles sin ventana” y los “alien widgets” de Qt.
  • Incluso toolkits modernos como Qt hacen que las listas con muchos QWidget sean lentas; el dibujo personalizado más el manejo de eventos para los elementos de la lista escala mejor.
  • En Windows, GDI solía dibujar directamente en VRAM; con el Desktop Window Manager, las ventanas ahora se componen como texturas, más cerca de la historia moderna de composición de X.

Áreas cliente y no cliente, y decoraciones

  • Windows clásico distingue entre áreas cliente y no cliente (barra de título, bordes, botones), cada una con mensajes separados; normalmente las apps dejan que los valores predeterminados gestionen la parte no cliente.
  • OS/2 Presentation Manager trataba todo, incluida el área cliente, como ventanas hijas, simplificando el modelo a costa potencial de velocidad.
  • El manejo de la parte no cliente ayuda a que mover o cerrar ventanas siga siendo responsivo incluso cuando las apps están ocupadas o colgadas; algunos lo comparan favorablemente con las decoraciones del lado del cliente en Linux/Wayland, donde las apps congeladas pueden ser más difíciles de gestionar.
  • Hay un desacuerdo continuo sobre las decoraciones del lado del cliente: algunos valoran la consistencia mediante marcos del lado del servidor; otros señalan que las apps diseñadas para CSD (por ejemplo, algunas apps de Linux) se ven mejor así.

Modelo cliente/servidor de X y terminología

  • Varios comentarios defienden que el “servidor” de X es el sistema de pantalla y los “clientes” son las apps: es análogo a servidores de archivos/impresión/bases de datos que median el acceso a un recurso.
  • La confusión proviene sobre todo del marketing de “computación cliente-servidor” de los años 90 y de modelos mentales centrados en el usuario donde “mi máquina local es el cliente”.
  • La gente enfatiza que la terminología de X encaja con las normas de redes una vez que se explica.

Captura de entrada y peculiaridades de interacción

  • XGrabPointer/XGrabKeyboard enrutan eventos a una ventana específica independientemente del foco del puntero, lo que permite funciones como menús en cascada y comportamientos robustos al arrastrar.
  • Existen mecanismos similares en otros lugares (por ejemplo, la captura del ratón en Windows); sin ellos, los arrastres que cruzan límites de ventana se comportarían mal.
  • El comportamiento de la rueda de desplazamiento difiere entre sistemas y épocas: algunos siempre desplazan la ventana bajo el cursor, otros históricamente requerían foco explícito; Windows añadió “desplazar ventanas inactivas” relativamente tarde.

Incrustar ventanas y composición

  • XEmbed aprovecha que “todo es una ventana” para que una app pueda ser contenedora de la ventana de otra (por ejemplo, contenedores con pestañas, navegadores incrustables, complementos de audio).
  • Win32 puede, técnicamente, reasignar la jerarquía de ventanas de nivel superior entre procesos, pero sufre problemas de rendimiento y complejidad (cambios de hilo/contexto, colas de entrada).
  • Algunos componentes modernos (por ejemplo, vistas web fuera de proceso) difuminan esta frontera mediante un entramado más complejo; se considera incierto cómo se mapea esto a Wayland.

Skins, temas y coherencia de la interfaz

  • Los controles nativos de Windows eran difíciles de decorar con skins, lo que impulsó las interfaces dibujadas a medida y las bibliotecas de skinning de terceros, especialmente alrededor de la era XP.
  • Esto produjo muchas interfaces “parecidas a XP pero equivocadas”, que imitaban visualmente los temas del sistema sin fidelidad al comportamiento ni a las métricas.
  • En el Mac clásico existían interfaces muy poco nativas, pero los usuarios a menudo las veían con malos ojos, como excepciones más que como la norma.
  • Hay una tensión entre dar libertad a las apps para dibujar todo y preservar un escritorio coherente, accesible, con apariencia y comportamiento consistentes.

Toolkits históricos y nostalgia

  • X se recuerda como elegante para su época, especialmente por su transparencia de red, pero los primeros toolkits (por ejemplo, Motif) eran dolorosos de usar.
  • Toolkits más nuevos como GTK y Tk resultaban más accesibles; otros recuerdan con cariño la API en C de XView, muy cargada de varargs.
  • Varios señalan que el estilo de “muchas ventanas pequeñas” ahora es un conocimiento relativamente oscuro entre desarrolladores modernos, aunque las ideas subyacentes siguen vivas en los DOM y en las jerarquías de vistas al estilo MVC.