El protocolo principal (raíz) del sistema X Window ( eng. protocolo central del sistema X Window ) es el formato para la interacción del sistema X Window , un sistema de ventana de red para terminales de video de trama . X Window se basa en un modelo cliente-servidor , es decir, un servidor administra todas las E/S, como pantalla(s), teclado y mouse, todas las aplicaciones funcionan como clientes, interactuando con el usuario y otros clientes a través del servidor. Esta interacción la proporciona el protocolo raíz. También hay otros protocolos que son "complementos" en la parte superior de la raíz y completamente independientes.
El protocolo raíz del sistema X Window proporciona solo 4 tipos de paquetes de datos enviados de forma asíncrona a través de la red: solicitudes, respuestas, eventos y mensajes de error. Las solicitudes son enviadas por el cliente al servidor para realizar alguna acción (por ejemplo, crear una nueva ventana) y/o decirle al servidor que devuelva algunos datos. La respuesta del servidor garantiza que estos datos se envíen al cliente. Los eventos son enviados por un servidor para notificar a sus clientes sobre la actividad del usuario u otra actividad del lado del servidor que le interese a un cliente en particular. Los mensajes de error son enviados por el servidor a su cliente en caso de errores en el procesamiento de las solicitudes del cliente. Las solicitudes pueden generar respuestas, eventos o mensajes de error. El protocolo no establece una secuencia obligatoria para la transmisión de paquetes por la red. Hay extensiones del protocolo raíz con sus propias solicitudes, respuestas, eventos o mensajes de error.
System X apareció en el MIT en 1984 (la versión actual de X11 es de septiembre de 1987). Su desarrollador, Bob Shifler y Jim Geths, se guiaron por la regla durante su desarrollo de que el protocolo raíz debe establecer "un mecanismo, no un conjunto de reglas de política". Como resultado, el protocolo raíz no especifica la interacción entre clientes y entre cliente y usuario. Están sujetos a especificaciones adicionales [1] como ICCCM y Freedesktop.org y, por lo general, se realizan automáticamente mediante un conjunto predefinido de widgets .
La comunicación entre el servidor y los clientes se realiza mediante el intercambio de paquetes a través de un canal. La conexión la establece el cliente (el protocolo no define cómo se inicia el cliente). Además, el cliente envía un primer paquete que contiene el endianness a utilizar e información sobre la versión del protocolo, así como el tipo de autenticación que espera el cliente, para uso del servidor. El servidor responde devolviendo un paquete que confirma o deniega la conexión, o solicita una autenticación adicional. Si se confirma la conexión, se envía un paquete que contiene los datos al cliente para su uso en la interacción posterior con el servidor.
Una vez que se establece una conexión, se utilizan cuatro tipos de paquetes para intercambiar entre el cliente y el servidor a través del canal:
Las solicitudes y respuestas se envían en paquetes de diferentes longitudes, mientras que los paquetes de eventos y errores tienen una longitud fija de 32 bytes .
Lo que comúnmente se denomina ventana en la mayoría de las interfaces gráficas de usuario en el sistema X Window se denomina ventana de nivel superior. El término ventana también se usa para referirse a las ventanas que se encuentran dentro de otra ventana, es decir, una ventana secundaria de una ventana principal. Los elementos gráficos como botones, menús, iconos, etc. se pueden implementar mediante una subventana.
El cliente podrá solicitar la creación de una ventana. Más precisamente, puede solicitar la creación de una subventana dentro de una ventana existente. Como resultado, las ventanas creadas por los clientes se organizan en un árbol (jerarquía). La raíz de este árbol es la ventana raíz, que es una ventana especial creada automáticamente cuando se inicia el servidor. Todas las demás ventanas son directa o indirectamente subventanas de la ventana raíz. Las ventanas de nivel superior son subventanas directas de la ventana raíz. Obviamente, la ventana raíz tiene el mismo tamaño que la pantalla (aunque puede ser más grande, en cuyo caso el usuario puede mover el área visible) y subyace a todas las demás ventanas.
No siempre se garantiza que el contenido de una ventana se conserve a lo largo del tiempo. En particular, el contenido de una ventana puede destruirse cuando la ventana se mueve, cambia de tamaño, se cubre con otras ventanas y, en general, se vuelve total o parcialmente invisible. En particular, el contenido se pierde si el servidor X no admite almacenar el contenido de la ventana en la memoria auxiliar. El cliente puede solicitar que el contenido de la ventana se guarde en la memoria auxiliar, pero el servidor no está obligado a hacerlo. Por lo tanto, los clientes no pueden asumir que existe soporte de memoria auxiliar. Si la parte visible de la ventana tiene un contenido indefinido, el evento envía un mensaje al cliente de que el contenido de la ventana debe dibujarse nuevamente.
Cada ventana tiene un conjunto de atributos asociado, como la geometría de la ventana (tamaño y posición), imágenes de fondo, si se solicita que se guarde en la memoria auxiliar, etc. El protocolo contiene solicitudes al cliente para verificar y cambiar los atributos de la ventana. .
Windows puede ser InputOutput o InputOnly. Las ventanas del primer tipo pueden mostrarse en la pantalla y usarse para dibujar. El segundo tipo de ventanas no se muestran en la pantalla, solo se utilizan para recibir información.
El borde decorativo y la barra de título (que posiblemente incluyan botones) que se ven comúnmente alrededor de las ventanas son creados por el administrador de ventanas , no por el cliente que crea la ventana. El administrador de ventanas también administra la entrada asociada con estos elementos, como el cambio de tamaño de la ventana cuando el usuario hace clic y arrastra el marco de la ventana. Los clientes suelen trabajar en una ventana, se crean sin tener en cuenta los cambios realizados por el administrador de ventanas. Considere también los administradores de ventanas que reemplazan la ventana raíz principal común para las ventanas de nivel superior. La mayoría de los administradores de ventanas hacen esto ahora. Desde el punto de vista del protocolo subyacente, el administrador de ventanas es un cliente como otras aplicaciones.
La información sobre la ventana se puede obtener ejecutando el programa xwininfo. Cuando se ejecuta desde la línea de comandos con el argumento --tree, este programa muestra el árbol de subventanas de la ventana, junto con sus identificadores y datos geométricos.
La imagen de mapa de bits se almacena en la memoria del servidor, no se muestra en la pantalla, pero se puede dibujar total o parcialmente en la ventana. El contenido de una ventana se puede guardar como un mapa de bits. Esto permite el doble almacenamiento en búfer. Las operaciones gráficas aplicables a las ventanas también son aplicables a los mapas de bits.
Las ventanas y los mapas de bits se denominan áreas de dibujo. El contenido de las áreas de dibujo se almacena en el servidor. El cliente puede enviar una solicitud para transferir el contenido del área del servidor al cliente, o viceversa.
El cliente puede solicitar varias operaciones gráficas como limpiar un área, copiar un área a otra, dibujar puntos, líneas, rectángulos y texto. Además de borrar, todas las operaciones se pueden realizar en todas las áreas de dibujo.
La mayoría de las solicitudes de operaciones gráficas incluyen un contexto gráfico, una estructura de datos que contiene parámetros para operaciones gráficas. El contexto de los gráficos incluye el color de primer plano, el color de fondo, la fuente del texto y otras configuraciones. Al solicitar operaciones gráficas, el cliente incluye un contexto gráfico. No todas las configuraciones de contexto de gráficos afectan la operación: por ejemplo, la fuente no afecta el dibujo de la línea.
El protocolo central exige el uso de fuentes del lado del servidor. Estas fuentes se almacenan como archivos y el servidor accede a ellas directamente a través del sistema de archivos local oa través de la red utilizando otro programa llamado servidor de fuentes. El cliente puede solicitar una lista de fuentes disponibles en el servidor, puede solicitar cargar alguna fuente en el servidor (si dicha fuente no está ya en el servidor) o cargar una fuente (si no la utilizan otros clientes) en el servidor. El cliente puede solicitar información sobre la fuente (por ejemplo, el ascenso de la fuente) y el espacio que ocupa una línea en particular cuando se dibuja en una fuente en particular.
Los nombres de fuentes al nivel del protocolo principal de X Window son cadenas arbitrarias. La convención lógica de fuentes para X especifica exactamente cómo se deben nombrar las fuentes de acuerdo con sus atributos. Estas convenciones también especifican los valores de propiedades adicionales que pueden tener las fuentes.
El programa xlsfonts muestra una lista de fuentes almacenadas en el servidor, muestra símbolos de fuentes y permite al usuario seleccionar un nombre de fuente para pegarlo en otra ventana.
La representación de fuentes del lado del servidor ahora se considera obsoleta y la mayoría de los clientes (GTK, Qt) ya están realizando la representación de fuentes. Para renderizar fuentes, los clientes usan las bibliotecas Xft o cairo y las extensiones XRender. La especificación del protocolo central no describe la representación de fuentes del lado del cliente.
Todos los datos sobre ventanas, mapas de bits, fuentes y otros objetos se almacenan en el servidor. El cliente almacena los identificadores (números únicos) de estos objetos y los usa como nombres cuando interactúa con el servidor. Por ejemplo, un cliente que desea crear una ventana envía una solicitud al servidor para crear una ventana con la ID dada. El identificador puede ser utilizado por el cliente posteriormente, por ejemplo, para solicitar líneas para dibujar en la ventana. Los siguientes objetos se almacenan en el servidor y están disponibles para el cliente a través de identificadores digitales:
Estos objetos se denominan recursos. Cuando un cliente solicita la creación de uno de estos recursos, también especifica su identificador . Por ejemplo, para crear una nueva ventana, el cliente especifica los atributos de la ventana (principales, ancho, alto, etc.) y un identificador asociado con la ventana.
Los identificadores son números enteros de 32 bits cuyos tres bits más significativos son siempre cero. Cada cliente tiene su propio conjunto de ID que se pueden usar para crear nuevos recursos. El servidor emite este conjunto en un paquete de reconocimiento (el paquete enviado al cliente para indicar que se ha aceptado la conexión) y se representa como dos números. Los clientes seleccionan identificadores de este conjunto de tal manera que diferentes objetos tienen identificadores diferentes.
Una vez que se ha creado un recurso, el cliente puede utilizar su ID en solicitudes al servidor. Algunas operaciones afectan a estos recursos (por ejemplo, una solicitud para mover una ventana), otras solicitudes de recursos almacenados en el servidor (por ejemplo, solicitudes de atributos de ventana).
Los identificadores son únicos no solo para el cliente, sino también para el servidor. Por lo tanto, dos ventanas no pueden tener el mismo ID, aunque hayan sido creadas por dos clientes diferentes. Un cliente puede acceder a cualquier objeto por su identificador (incluso el objeto de otro cliente).
Como resultado, dos clientes conectados al mismo servidor pueden usar el mismo identificador para referirse al mismo recurso. Por ejemplo, si un cliente crea una ventana con ID 0x1e00021 y pasa ese número 0x1e00021 a otra aplicación (por cualquier medio disponible, como guardar ese número en un archivo al que también pueden acceder otras aplicaciones), esa otra aplicación puede ejecutarse en el mismo ventana. . Esta característica, por ejemplo, es utilizada por la versión X Window del programa Ghostview : este programa crea una ventana secundaria, almacena su identificador en una variable de entorno y llama a Ghostscript , que dibuja el contenido del archivo PostScript y lo muestra en este ventana [8].
Los recursos normalmente se destruyen después de que el cliente que los creó cierra la conexión con el servidor. Sin embargo, antes de cerrar la conexión, el cliente puede enviar una solicitud al servidor pidiéndole que no los destruya.
Los eventos son paquetes enviados por el servidor al cliente, con un mensaje de que sucedió lo que el cliente esperaba. Por ejemplo, se envía un evento cuando el usuario presiona una tecla o presiona un botón del mouse. Los eventos se pueden usar para algo más que una simple entrada: por ejemplo, los eventos envían una indicación para crear nuevas subventanas en una ventana determinada.
Cada evento está asociado a una ventana. Por ejemplo, si el usuario hace clic con el mouse, el evento se referirá a la ventana sobre la que estaba el cursor en el momento del clic. El paquete de eventos contendrá el ID de esta ventana.
El cliente puede solicitar al servidor que envíe un evento a otro cliente. Esto se utiliza para organizar la interacción entre los clientes. Tal evento, por ejemplo, se genera cuando un cliente solicita un texto seleccionado y el servidor lo envía al cliente propietario de la ventana con el texto seleccionado.
El servidor envía un evento Exposesi la imagen del área de la ventana del cliente se ha borrado de la memoria y la ventana se vuelve visible. La imagen de la ventana se borra de la memoria si la ventana se minimizó, se cubrió con otra ventana y en otros casos.
La mayoría de los tipos de eventos solo se envían al cliente si previamente ha declarado su interés en ellos. Por ejemplo, un cliente puede estar interesado en los eventos del teclado pero no en los eventos del mouse. A pesar de esto, algunos tipos de eventos se transmiten a los clientes incluso si no los solicitaron específicamente.
El cliente selecciona los tipos de eventos necesarios configurando un atributo de ventana especial: la máscara de eventos. Por ejemplo, para comenzar a dibujar el contenido de una ventana, el cliente debe recibir el archivo Expose. Sin embargo, el servidor solo enviará este evento si el cliente ha establecido el bit apropiado en la máscara de eventos de la ventana.
Diferentes clientes pueden solicitar eventos desde la misma ventana. Incluso pueden configurar diferentes máscaras de eventos en la misma ventana. Por ejemplo, un cliente puede solicitar solo eventos de teclado, mientras que otro solo puede solicitar eventos de mouse. Sin embargo, hay varios tipos de eventos que solo se pueden entregar a un cliente. En particular, estos son eventos de mensajes de clic del mouse y algunos cambios relacionados con la administración de ventanas.
xev- un programa que muestra eventos en relación con la ventana. En particular, el comando xev -id WIDconsulta todos los posibles eventos relacionados con la ventana con el identificador WIDy los imprime.
El siguiente es un ejemplo de una posible interacción entre un servidor y un programa que crea una ventana con una imagen de cuadro negro y sale de sus pulsaciones de teclas. En este ejemplo, el servidor no envía ninguna respuesta porque el cliente envía una solicitud que no genera respuestas. Estas consultas pueden generar errores.
Si una ventana se superpone a otra ventana y no vuelve a superponerse, siempre que no se administre el almacén de respaldo, entonces:
A nivel de protocolo, un color se representa mediante un número entero sin signo de 32 bits llamado valor de píxel . Los siguientes elementos toman parte en la representación del color:
En el caso más simple, un mapa de colores contiene una tríada RGB en una fila. pixelvalue xes la fila x de la tabla. Si el cliente puede cambiar las entradas en el mapa de colores, la vista se identifica con la clase visual PseudoColor . La clase visual StaticColores similar, pero el cliente no puede cambiar las entradas en la tabla de colores.
Hay un total de 6 clases visuales disponibles. Cada uno se define por una forma diferente de representar una tríada RGB con un valor de píxel. PseudoColory StaticColorlos dos primeros. Los dos siguientes - GrayScaley StaticGray, difieren en que solo muestran tonos de gris.
Las dos clases visuales restantes difieren de las anteriores en que no utilizan la tríada de valor de píxel, sino que utilizan tres tablas diferentes para los valores de intensidad de rojo, verde y azul.
Según la representación de los colores, el valor de píxel se convierte en tríada RGB en los siguientes casos:
Este mecanismo requiere que el mapa de colores esté compuesto por tres tablas separadas, cada una para uno de los colores primarios. El resultado de la transformación son otros tres valores de intensidad. Las clases visuales que utiliza esta vista son: DirectColoror TrueColor, diferenciándose en que el cliente puede cambiar el mapa de colores o no.
Todos estos seis mecanismos para representar colores con valor de píxel requieren algunos parámetros adicionales para funcionar. Estas opciones se recogen en un tipo visual que contiene la clase visual y el resto de opciones de representación de colores. Cada servidor tiene un número limitado de tipos visuales instalados y cada tipo está asociado con un identificador numérico. Los identificadores son números enteros sin signo de 32 bits, pero no son necesariamente diferentes de los identificadores de recursos o átomos.
Cuando se acepta una conexión del cliente, el paquete de reconocimiento enviado al servidor contiene una secuencia de bloques, cada uno con información sobre una pantalla. Para cada pantalla, los bloques relativos contienen una lista de otros bloques, cada bloque relativo define la profundidad de color admitida por la pantalla. Para cada profundidad de color, esta lista contiene los tipos visuales. Como resultado, cada pantalla está asociada con algunos posibles valores de profundidad de color y cada profundidad de color de cada pantalla está asociada con posibles tipos visuales. Estos tipos visuales se pueden usar para otras pantallas y diferentes profundidades de color.
Para cada tipo visual, el paquete de acuse de recibo contiene estos dos identificadores y los parámetros de contenido reales (tipo visual, etc.) El cliente almacena esta información, ya que no podrá volver a solicitar esta información en el futuro. Además, los clientes no pueden cambiar ni crear nuevos tipos visuales. Las solicitudes para crear una nueva ventana incluyen la profundidad de color y el identificador de tipo visual para mostrar los colores en esa ventana.
Los mapas de colores se usan independientemente del hardware que controla la pantalla (es decir, la tarjeta de video puede o no usar una paleta (tabla de colores). Los servidores usan mapas de colores incluso si el hardware no usa una paleta. Cuando el hardware utiliza paletas, se puede instalar un número limitado de mapas de colores. En particular, los mapas de colores se configuran cuando el hardware muestra colores uniformes. El cliente puede solicitar al servidor que instale un mapa de colores. Sin embargo, esto puede requerir la eliminación de otro mapa de color: el efecto de usar el mapa de color eliminado será una imagen con colores incorrectos, un efecto de ráfaga de color doble o colores de alta intensidad. Este problema se puede resolver utilizando mapas de color estándar. Estos son mapas de colores con asociaciones predefinidas entre valores de píxeles y colores. Gracias a esta cualidad, los mapas de colores estándar pueden ser utilizados por varias aplicaciones.
La creación de mapas en color se rige por el acuerdo ICCCM. Los mapas de colores estándar están definidos por la especificación ICCCM y Xlib.
Parte del sistema de color X es el Sistema de gestión de color X (xcms). Este sistema apareció con X11R6 Release 5 en 1991. Este sistema está contenido en forma de varias características adicionales de Xlib que se encuentran en una serie de funciones cuyos nombres comienzan con Xcms. El sistema define esquemas de color independientes del dispositivo que ya se pueden convertir a sistemas RGB dependientes del dispositivo. El sistema contiene las funciones Xlib Xcms*, así como la convención de caracterización de color del dispositivo X (XDCCC), que describe cómo varios sistemas de color independientes del dispositivo se convierten en sistemas de color RGB dependientes del dispositivo. Este sistema es compatible con los sistemas de color CIEXYZ, xyY, CIELUV y CIELAB, así como con TekHVC.
| Sistema de ventana X | |
|---|---|
| Arquitectura |
|
| Administradores de ventanas | |
| Extensiones |
|
| Implementaciones |
|
| Estándares | |
| Aplicaciones |
|