El protocolo central del sistema X Window [1] [2] [3] es el protocolo base del sistema X Window , que es un sistema de ventanas en red para pantallas de mapa de bits utilizado para crear interfaces gráficas de usuario en Unix , similares a Unix y otros sistemas operativos. sistemas . El sistema X Window se basa en un modelo cliente-servidor : un único servidor controla el hardware de entrada/salida , como la pantalla , el teclado y el ratón ; Todos los programas de aplicación actúan como clientes , interactuando con el usuario y con los demás clientes a través del servidor. Esta interacción está regulada por el protocolo central del sistema X Window. Existen otros protocolos relacionados con el sistema X Window, ambos integrados en la parte superior del protocolo central del sistema X Window o como protocolos separados.
En el protocolo central del sistema X Window, sólo se envían cuatro tipos de paquetes, de forma asíncrona, a través de la red: solicitudes, respuestas, eventos y errores. Un cliente envía solicitudes al servidor para pedirle que realice alguna operación (por ejemplo, crear una nueva ventana) y que envíe los datos que contiene. Las respuestas son enviadas por el servidor para proporcionar dichos datos. El servidor envía eventos para notificar a los clientes sobre la actividad del usuario u otros sucesos que les interesen. Los errores son paquetes enviados por el servidor para notificar a un cliente sobre los errores ocurridos durante el procesamiento de sus solicitudes. Las solicitudes pueden generar respuestas, eventos y errores; Aparte de esto, el protocolo no exige un orden específico en el que se envían los paquetes a través de la red. Existen algunas extensiones del protocolo central, cada una con sus propias solicitudes, respuestas, eventos y errores.
X se originó en el MIT en 1984 (su [actualizar]versión actual, X11, apareció en septiembre de 1987). Sus diseñadores Bob Scheifler y Jim Gettys establecieron como principio inicial que su protocolo central era "crear mecanismos, no políticas". Como resultado, el protocolo central no especifica la interacción entre clientes y entre un cliente y el usuario. Estas interacciones son objeto de especificaciones separadas, [4] como las especificaciones ICCCM y freedesktop.org , y generalmente se aplican automáticamente mediante el uso de un conjunto de widgets determinado .
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 (cómo se inicia el cliente no se especifica en el protocolo). El cliente también envía el primer paquete, que contiene el orden de bytes que se utilizará e información sobre la versión del protocolo y el tipo de autenticación que el cliente espera que utilice el servidor. El servidor responde devolviendo un paquete indicando la aceptación o el rechazo de la conexión, o con una solicitud de nueva autenticación . Si se acepta la conexión, el paquete de aceptación contiene datos para que el cliente los utilice en la interacción posterior con el servidor.
Una vez establecida la conexión, se intercambian cuatro tipos de paquetes entre el cliente y el servidor a través del canal:
Los paquetes de solicitud y respuesta tienen una longitud variable, mientras que los paquetes de eventos y errores tienen una longitud fija de 32 bytes .
Los paquetes de solicitud son numerados secuencialmente por el servidor tan pronto como los recibe: la primera solicitud de un cliente se numera 1, la segunda 2, etc. Los 16 bits menos significativos del número secuencial de una solicitud se incluyen en la respuesta y el error. paquetes generados por la solicitud, si los hubiera. También se incluyen en paquetes de eventos para indicar el número secuencial de la solicitud que el servidor está procesando actualmente o que acaba de terminar de procesar.
Lo que normalmente se llama ventana en la mayoría de las interfaces gráficas de usuario se llama ventana de nivel superior en el sistema X Window. El término ventana también se utiliza para indicar ventanas que se encuentran dentro de otra ventana, es decir, las subventanas de una ventana principal . Los elementos gráficos como botones , menús , iconos , etc. se pueden realizar mediante subventanas.
Un cliente puede solicitar la creación de una ventana. Más precisamente, puede solicitar la creación de una subventana de una ventana existente. Como resultado, las ventanas creadas por los clientes se organizan en un árbol (una jerarquía). La raíz de este árbol es la ventana raíz , que es una ventana especial creada automáticamente por el servidor al inicio. Todas las demás ventanas son directa o indirectamente subventanas de la ventana raíz. Las ventanas de nivel superior son las subventanas directas de la ventana raíz. Visiblemente, la ventana raíz es tan grande como el escritorio virtual y se encuentra detrás de todas las demás ventanas.
No siempre se garantiza que el contenido de una ventana se conserve en el tiempo. En particular, el contenido de la ventana puede destruirse cuando la ventana se mueve, se cambia de tamaño, se cubre con otras ventanas y, en general, se hace total o parcialmente no visible. En particular, el contenido se pierde si el servidor X no mantiene un almacén de respaldo del contenido de la ventana. El cliente puede solicitar que se mantenga una ventana en el almacén de respaldo, pero el servidor no tiene la obligación de hacerlo. Por lo tanto, los clientes no pueden asumir que se mantiene el almacén de respaldo. Si una parte visible de una ventana tiene un contenido no especificado, se envía un evento para notificar al cliente 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), la imagen de fondo, si se ha solicitado una tienda de respaldo, etc. El protocolo incluye solicitudes para que un cliente inspeccione y cambie los atributos. de una ventana.
Windows puede ser InputOutputo InputOnly. InputOutputLas ventanas se pueden mostrar en la pantalla y se utilizan para dibujar. InputOnlyLas ventanas nunca se muestran en la pantalla y se usan solo para recibir información.
.png/1280px-Xframe_(en).png)
El marco decorativo y la barra de título (que posiblemente incluyan botones) que generalmente se ven 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 maneja entradas relacionadas con estos elementos, como cambiar el tamaño de la ventana cuando el usuario hace clic y arrastra el marco de la ventana. Los clientes normalmente operan en la ventana que crearon sin tener en cuenta los cambios realizados por el administrador de ventanas. Un cambio que debe tenerse en cuenta es que los administradores de ventanas re-parenting , que son casi todos los administradores de ventanas modernos, cambian el padre de las ventanas de nivel superior a una ventana que no es la raíz. Desde el punto de vista del protocolo central, el administrador de ventanas es un cliente, no diferente de otras aplicaciones.
Los datos sobre una ventana se pueden obtener ejecutando el xwininfoprograma. Al pasarle el -tree argumento de la línea de comandos , este programa muestra el árbol de subventanas de una ventana, junto con sus identificadores y datos de geometría.
Un mapa de píxeles es una región de la memoria que se puede utilizar para dibujar. A diferencia de Windows, los mapas de píxeles no se muestran automáticamente en la pantalla. Sin embargo, el contenido de un mapa de píxeles (o una parte de él) se puede transferir a una ventana y viceversa. Esto permite técnicas como el doble almacenamiento en búfer . La mayoría de las operaciones gráficas que se pueden realizar en Windows también se pueden realizar en mapas de píxeles.
Windows y pixmaps se denominan colectivamente elementos dibujables y sus datos de contenido residen en el servidor. Sin embargo, un cliente puede solicitar que el contenido de un diseño se transfiera del servidor al cliente o viceversa.
El cliente puede solicitar una serie de operaciones gráficas, como limpiar un área, copiar un área en otra, dibujar puntos, líneas, rectángulos y texto. Además de borrar, todas las operaciones son posibles en todos los elementos dibujables, tanto en ventanas como en mapas de píxeles.
La mayoría de las solicitudes de operaciones gráficas incluyen un contexto gráfico , que es una estructura que contiene los parámetros de las operaciones gráficas. Un contexto gráfico incluye el color de primer plano, el color de fondo, la fuente del texto y otros parámetros gráficos. Al solicitar una operación gráfica, el cliente incluye un contexto gráfico. No todos los parámetros del contexto gráfico afectan la operación: por ejemplo, la fuente no afecta el dibujo de una línea.
El protocolo central especifica el uso de fuentes del lado del servidor. [5] Estas fuentes se almacenan como archivos y el servidor accede a ellas directamente a través del sistema de archivos local o a través de la red desde otro programa llamado servidor de fuentes . Los clientes pueden solicitar la lista de fuentes disponibles para el servidor y pueden solicitar que el servidor cargue (si aún no está) o descargue (si no la utilizan otros clientes) una fuente. Un cliente puede solicitar información general sobre una fuente (por ejemplo, el ascenso de la fuente) y el espacio que ocupa una cadena específica cuando se dibuja con una fuente específica.
xfontselprograma permite al usuario ver los glifos de una fuente.Los nombres de las fuentes son cadenas arbitrarias al nivel del protocolo central de X Window. Las convenciones de descripción de fuentes lógicas X [6] especifican cómo se deben nombrar las fuentes según sus atributos. Estas convenciones también especifican los valores de propiedades opcionales que se pueden adjuntar a las fuentes.
El xlsfontsprograma imprime la lista de fuentes almacenadas en el servidor. El xfontselprograma muestra los glifos de las fuentes y permite al usuario seleccionar el nombre de una fuente para pegarla en otra ventana.
Actualmente, el uso de fuentes del lado del servidor se considera obsoleto en favor de las fuentes del lado del cliente. [7] Estas fuentes son renderizadas por el cliente, no por el servidor, con el soporte de las bibliotecas Xft o cairo y la extensión XRender . En el protocolo principal no se proporciona ninguna especificación sobre las fuentes del lado del cliente.
Todos los datos sobre ventanas, mapas de píxeles, fuentes, etc. se almacenan en el servidor. El cliente conoce los identificadores de estos objetos: números enteros que utiliza como nombres cuando interactúa con el servidor. Por ejemplo, si un cliente desea que se cree una ventana, solicita al servidor que cree una ventana con un identificador determinado. El cliente puede utilizar posteriormente el identificador para solicitar, por ejemplo, que se dibuje una cadena en la ventana. Los siguientes objetos residen en el servidor y el cliente los conoce mediante un identificador numérico:
WindowPixmapFontColormap(una tabla de colores, descrita a continuación)Graphic contextEstos objetos se llaman recursos . Cuando un cliente solicita la creación de uno de esos recursos, también especifica un identificador para él. Por ejemplo, para crear una nueva ventana, el cliente especifica los atributos de la ventana (principal, ancho, alto, etc.) y el identificador para asociar con la ventana.
Los identificadores son números enteros de 32 bits con sus tres bits más significativos iguales a cero. Cada cliente tiene su propio conjunto de identificadores que puede utilizar para crear nuevos recursos. Este conjunto lo especifica el servidor como dos números enteros incluidos en el paquete de aceptación (el paquete que envía al cliente para informarle que se acepta la conexión). Los clientes eligen los identificadores que están en este conjunto de tal manera que no entren en conflicto: dos objetos entre ventanas, mapas de píxeles, fuentes, mapas de colores y contextos gráficos no pueden tener el mismo identificador.
Una vez que se ha creado un recurso, el cliente utiliza su identificador para solicitar operaciones sobre él al servidor. Algunas operaciones afectan el recurso dado (por ejemplo, solicitudes para mover ventanas); otros solicitan datos de recursos almacenados en el servidor (por ejemplo, solicitudes de atributos de Windows).
Los identificadores son exclusivos del servidor, no sólo del cliente; por ejemplo, no hay dos ventanas que tengan el mismo identificador, incluso si fueron creadas por dos clientes diferentes. Un cliente puede acceder a cualquier objeto dado su identificador. En particular, también puede acceder a recursos creados por cualquier otro cliente, incluso si sus identificadores están fuera del conjunto de identificadores que puede crear.
Como resultado, dos clientes conectados al mismo servidor pueden utilizar el mismo identificador para referirse al mismo recurso. Por ejemplo, si un cliente crea una ventana de identificador 0x1e00021y pasa este número 0x1e00021a otra aplicación (a través de cualquier medio disponible, por ejemplo almacenando este número en un archivo al que también puede acceder la otra aplicación), esta otra aplicación puede operar en la misma ventana. Esta posibilidad es aprovechada, por ejemplo, por la versión X Window de Ghostview : este programa crea una subventana, almacena su identificador en una variable de entorno y llama a Ghostscript ; este programa dibuja el contenido del archivo PostScript para mostrarlo en esta ventana. [8]
Los recursos normalmente se destruyen cuando el cliente que los creó cierra la conexión con el servidor. Sin embargo, antes de cerrar la conexión, un cliente puede solicitar al servidor que no los destruya.
Los eventos son paquetes enviados por el servidor a un cliente para comunicar que ha sucedido algo que puede interesarle. Por ejemplo, se envía un evento cuando el usuario presiona una tecla o hace clic en un botón del mouse. Los eventos no solo se utilizan como entrada: por ejemplo, los eventos se envían para indicar la creación de nuevas subventanas de una ventana determinada.
Cada evento es relativo a una ventana. Por ejemplo, si el usuario hace clic cuando el puntero está en una ventana, el evento será relativo a esa ventana. El paquete de eventos contiene el identificador de esa ventana.
Un cliente puede solicitar al servidor que envíe un evento a otro cliente; esto se utiliza para la comunicación entre clientes. Un evento de este tipo se genera, por ejemplo, cuando un cliente solicita el texto actualmente seleccionado: este evento se envía al cliente que actualmente está manejando la ventana que contiene la selección.
El Exposeevento se envía cuando un área de una ventana de contenido destruido se hace visible. El contenido de una ventana puede destruirse en algunas condiciones, por ejemplo, si la ventana está cubierta y el servidor no mantiene un almacén de respaldo. El servidor genera un Exposeevento para notificar al cliente que se debe dibujar una parte de la ventana.
La mayoría de los tipos de eventos se envían sólo si el cliente ha manifestado previamente su interés en ellos. Esto se debe a que es posible que los clientes solo estén interesados en algún tipo de eventos. Por ejemplo, un cliente puede estar interesado en eventos relacionados con el teclado pero no en eventos relacionados con el mouse. Sin embargo, algunos tipos de eventos se envían a los clientes incluso si no los han solicitado específicamente.
Los clientes especifican qué tipos de eventos quieren que se envíen configurando un atributo de una ventana. Por ejemplo, para volver a dibujar una ventana cuando su contenido ha sido destruido, un cliente debe recibir los Exposeeventos que le informan que es necesario volver a dibujar la ventana. Sin embargo, al cliente se le enviarán Exposeeventos solo si el cliente ha manifestado previamente su interés en estos eventos, lo cual se hace configurando adecuadamente el atributo de máscara de evento de la ventana.
Diferentes clientes pueden solicitar eventos en 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 en una ventana mientras que otro cliente solo solicita eventos de mouse en la misma ventana. Esto es posible porque el servidor, para cada ventana, mantiene una máscara de evento separada para cada cliente. Sin embargo, hay algunos tipos de eventos que solo pueden ser seleccionados por un cliente a la vez para cada ventana. En particular, estos eventos informan clics en el botón del mouse y algunos cambios relacionados con la administración de ventanas.
El xevprograma muestra los eventos relativos a una ventana. En particular, xev -id WIDsolicita todos los eventos posibles relacionados con la ventana del identificador WIDy los imprime.
El siguiente es un posible ejemplo de interacción entre un servidor y un programa que crea una ventana con un cuadro negro y sale al presionar una tecla. En este ejemplo, el servidor no envía ninguna respuesta porque las solicitudes del cliente no generan respuestas. Estas solicitudes podrían generar errores.
0x0000002b) y qué identificadores puede crear el cliente.0x00200000(esta solicitud, como las demás solicitudes de este ejemplo, no genera respuestas del servidor)0x0000002b) con identificador 0x00200001, tamaño 200x200, posición (10,10), etc.0x00200001, especificando que está interesado en recibir Exposeeventos KeyPress.0x00200001que se mapee la ventana (se muestra en pantalla)ExposeeventoPolyFillRectanglesolicitud con ventana 0x00200001y contexto gráfico.0x00200000Si la ventana se cubre con otra ventana y se vuelve a descubrir, suponiendo que no se mantenga el almacén de respaldo:
Exposeevento para decirle al cliente que la ventana debe dibujarse nuevamente.PolyFillRectanglesolicitud.Si se presiona una tecla:
KeyPressevento al cliente para notificarle que el usuario ha presionado una tecla.A nivel de protocolo, un color está representado por un entero sin signo de 32 bits, llamado valor de píxel . Los siguientes elementos afectan la representación de los colores:
En el caso más sencillo, el mapa de colores es una tabla que contiene un triplete RGB en cada fila. Un valor de píxel xrepresenta el color contenido en la xfila -ésima de la tabla. Si el cliente puede cambiar las entradas en el mapa de colores, esta representación se identifica mediante la PseudoColor clase visual . La clase visual StaticColores similar, pero el cliente no puede cambiar las entradas en el mapa de colores.
Hay un total de seis clases visuales posibles, cada una de las cuales identifica una forma diferente de representar un triple RGB con un valor de píxel. PseudoColory StaticColorson dos. Otros dos son GrayScaley StaticGray, que se diferencian en que sólo muestran tonos de gris.
Las dos clases visuales restantes se diferencian de las anteriores porque dividen los valores de píxeles en tres partes y utilizan tres tablas separadas para la intensidad de rojo, verde y azul. Según esta representación de color, un valor de píxel se convierte en un triple RGB de la siguiente manera:
Este mecanismo requiere que el mapa de colores esté compuesto por tres tablas separadas, una para cada color primario . El resultado de la conversión sigue siendo un triple de los valores de intensidad. Las clases visuales que utilizan esta representación son las DirectColory TrueColor, y se diferencian en si el cliente puede cambiar los mapas de colores o no.
Estos seis mecanismos para representar colores con valores de píxeles requieren algunos parámetros adicionales para funcionar. Estos parámetros se recopilan en un tipo visual , que contiene una clase visual y otros parámetros de representación de colores. Cada servidor tiene un conjunto fijo de tipos visuales, cada uno asociado con un identificador numérico. Estos identificadores son enteros sin signo de 32 bits, pero no son necesariamente diferentes de los identificadores de recursos o átomos.
Cuando se acepta la conexión de un cliente, el paquete de aceptación enviado por el servidor contiene una secuencia de bloques, cada uno de los cuales contiene información sobre una única pantalla. Para cada pantalla, el bloque relativo contiene una lista de otros bloques, cada uno de ellos relativo a una profundidad de color específica admitida por la pantalla. Para cada profundidad admitida, esta lista contiene una lista de tipos visuales. Como resultado, a cada pantalla se le asocia un número de posibles profundidades, y a cada profundidad de cada pantalla se le asocia un número de posibles tipos visuales. Un tipo visual determinado se puede utilizar para más pantallas y para diferentes profundidades.
Para cada tipo visual, el paquete de aceptación contiene tanto su identificador como los parámetros reales que contiene (clase visual, etc.). El cliente almacena esta información, ya que no puede solicitarla posteriormente. Además, los clientes no pueden cambiar ni crear nuevos tipos visuales. Las solicitudes de creación de una nueva ventana incluyen la profundidad y el identificador del tipo visual que se utilizará para representar los colores de esta ventana.
Los mapas de colores se utilizan independientemente de si el hardware que controla la pantalla (por ejemplo, una tarjeta gráfica ) utiliza una paleta , que es una tabla que también se utiliza para representar colores. Los servidores utilizan mapas de colores incluso si el hardware no utiliza una paleta. Siempre que el hardware utilice paletas, solo se podrá instalar un número limitado de mapas de colores. En particular, se instala un mapa de colores cuando el hardware muestra colores según él. Un cliente puede solicitar al servidor que instale un mapa de colores. Sin embargo, esto puede requerir la desinstalación de otro mapa de colores: el efecto es que las ventanas que utilizan el mapa de colores desinstalado no se muestran con el color correcto, un efecto denominado color intermitente o tecnicolor . Este problema se puede resolver utilizando mapas de colores estándar , que son mapas de colores con una asociación predecible entre valores de píxeles y colores. Gracias a esta propiedad, diferentes aplicaciones pueden utilizar mapas de colores estándar.
La creación de mapas de colores está regulada por la convención ICCCM . Los mapas de colores estándar están regulados por ICCCM y por la especificación Xlib .
Una parte del sistema de color X es el sistema de gestión de color X (xcms). Este sistema se introdujo con X11R6 versión 5 en 1991. Este sistema consta de varias características adicionales en xlib, que se encuentran en la serie de funciones Xcms*. Este sistema define esquemas de color independientes del dispositivo que se pueden convertir en sistemas RGB dependientes del dispositivo. El sistema consta de las funciones xlib Xcms* y también de la Convención de caracterización de color del dispositivo X (XDCCC), que describe cómo convertir los diversos sistemas de color independientes del dispositivo en sistemas de color RGB dependientes del dispositivo. Este sistema es compatible con CIEXYZ , xyY , CIELUV y CIELAB y también con los sistemas de color TekHVC. [1], [2]
Los átomos son números enteros de 32 bits que representan cadenas . Los diseñadores del protocolo introdujeron los átomos porque representan cadenas en un tamaño corto y fijo: [9] mientras que una cadena puede ser arbitrariamente larga, un átomo es siempre un entero de 32 bits. La brevedad de los átomos se aprovechó al exigir su uso en tipos de paquetes que probablemente se enviarán muchas veces con las mismas cadenas; esto resulta en un uso más eficiente de la red. El tamaño fijo de los átomos se aprovechó especificando un tamaño fijo para los eventos, concretamente 32 bytes: los paquetes de tamaño fijo pueden contener átomos, pero no pueden contener cadenas largas.
Precisamente, los átomos son identificadores de cadenas almacenadas en el servidor. Son similares a los identificadores de recursos (Windows, Pixmaps, etc.) pero se diferencian de ellos en dos aspectos. Primero, los identificadores de átomos los elige el servidor, no el cliente. En otras palabras, cuando un cliente solicita la creación de un nuevo átomo, solo envía al servidor la cadena a almacenar, no su identificador; este identificador es elegido por el servidor y enviado como respuesta al cliente. La segunda diferencia importante entre recursos y átomos es que los átomos no están asociados con clientes. Una vez creado, un átomo sobrevive hasta que el servidor se cierra o se reinicia (este no es el comportamiento predeterminado de los recursos).
Los átomos son identificadores y, por tanto, son únicos. Sin embargo, un átomo y un identificador de recurso pueden coincidir. La cadena asociada con un átomo se llama nombre del átomo . El nombre de un átomo no se puede cambiar después de su creación y no hay dos átomos que puedan tener el mismo nombre. Como resultado, el nombre de un átomo se usa comúnmente para indicar el átomo: "el átomo ABCD" significa, más precisamente, "el átomo cuya cadena asociada es ABCD". o "el átomo cuyo nombre es ABCD". Un cliente puede solicitar la creación de un nuevo átomo y puede solicitar el átomo (el identificador) de una cadena determinada. Algunos átomos están predefinidos (creados por el servidor con un identificador y una cadena determinados).
Los átomos se utilizan para diversos fines, principalmente relacionados con la comunicación entre diferentes clientes conectados al mismo servidor. En particular, se utilizan en asociación con las propiedades de las ventanas, que se describen a continuación.
La lista de todos los átomos que residen en un servidor se puede imprimir usando el programa xlsatoms. En particular, este programa imprime cada átomo (el identificador, es decir, un número) con su nombre (su cadena asociada).
Cada ventana tiene un conjunto predefinido de atributos y un conjunto de propiedades, todos almacenados en el servidor y accesibles para los clientes a través de las solicitudes apropiadas. Los atributos son datos sobre la ventana, como su tamaño, posición, color de fondo, etc. Las propiedades son datos arbitrarios adjuntos a una ventana. A diferencia de los atributos, las propiedades no tienen significado en el nivel del protocolo central de X Window. Un cliente puede almacenar datos arbitrarios en una propiedad de una ventana.
Una propiedad se caracteriza por un nombre, un tipo y un valor. Las propiedades son similares a las variables en los lenguajes de programación imperativos , en el sentido de que un cliente puede crear una nueva propiedad con un nombre y tipo determinados y almacenar un valor en ella. Las propiedades están asociadas a ventanas: dos propiedades con el mismo nombre pueden existir en dos ventanas diferentes y tener diferentes tipos y valores.
El nombre, tipo y valor de una propiedad son cadenas; más precisamente, son átomos, es decir, cadenas almacenadas en el servidor y accesibles a los clientes a través de identificadores. Una aplicación cliente puede acceder a una propiedad determinada utilizando el identificador del átomo que contiene el nombre de la propiedad.
Las propiedades se utilizan principalmente para la comunicación entre clientes. Por ejemplo, la propiedad nombrada WM_NAME(la propiedad nombrada por el átomo cuya cadena asociada es "WM_NAME") se usa para almacenar el nombre de las ventanas. Los administradores de ventanas normalmente leen esta propiedad para mostrar el nombre de las ventanas en su barra de título.
Algunos tipos de comunicación entre clientes utilizan propiedades de la ventana raíz. Por ejemplo, de acuerdo con la especificación del administrador de ventanas de freedesktop , [10] los administradores de ventanas deben almacenar el identificador de la ventana actualmente activa en la propiedad denominada _NET_ACTIVE_WINDOWde la ventana raíz. Los recursos X , que contienen parámetros de programas, también se almacenan en las propiedades de la ventana raíz; De esta manera, todos los clientes pueden acceder a ellos, incluso si se ejecutan en computadoras diferentes.
El xpropprograma imprime las propiedades de una ventana determinada; xprop -rootimprime el nombre, tipo y valor de cada propiedad de la ventana raíz.
/, 7y {están asociados a tres símbolos de clave diferentes .En el sistema X Window, cada clave física individual está asociada a un número en el rango de 8 a 255, llamado código clave . Un código clave sólo identifica una clave, no un carácter o término en particular (por ejemplo, "Re Pág") entre los que pueden estar impresos en la clave. Cada uno de estos caracteres o términos se identifica mediante un símbolo de clave . Mientras que un código clave solo depende de la tecla real que se presiona, un símbolo de clave puede depender, por ejemplo, de si también se presionó la tecla Shift u otro modificador .
Cuando se presiona o suelta una tecla, el servidor envía eventos de tipo KeyPresso KeyReleasea los clientes apropiados. Estos eventos contienen:
Por lo tanto, el servidor envía el código clave y el estado del modificador sin intentar traducirlos a un carácter específico. Es responsabilidad del cliente realizar esta conversión. Por ejemplo, un cliente puede recibir un evento que indique que se presionó una tecla determinada mientras el modificador Shift estaba presionado. Si esta clave normalmente generaría el carácter "a", el cliente (y no el servidor) asocia este evento al carácter "A".
Mientras que la traducción de códigos clave a símbolos clave la realiza el cliente, el servidor mantiene la tabla que representa esta asociación. Almacenar esta mesa en un lugar centralizado la hace accesible a todos los clientes. Los clientes típicos solo solicitan esta asignación y la usan para decodificar el código clave y el campo modificador de un evento clave en un símbolo de clave. Sin embargo, los clientes también pueden cambiar este mapeo a voluntad.
Un modificador es una tecla que, cuando se presiona, cambia la interpretación de otras teclas. Un modificador común es la tecla Shift : cuando la tecla que normalmente produce una "a" minúscula se presiona junto con Shift, produce una "A" mayúscula. Otros modificadores comunes son "Control", "Alt" y "Meta".
El servidor X funciona con como máximo ocho modificadores. Sin embargo, cada modificador puede asociarse con más de una clave. Esto es necesario porque muchos teclados tienen teclas duplicadas para algunos modificadores. Por ejemplo, muchos teclados tienen dos teclas "Shift" (una a la izquierda y otra a la derecha). Estas dos teclas producen dos códigos de tecla diferentes cuando se presionan, pero el servidor X asocia ambas con el modificador "Shift".
Para cada uno de los ocho modificadores, el servidor X mantiene una lista de los códigos clave que considera ese modificador. Como ejemplo, si la lista del primer modificador (el modificador "Shift") contiene el código clave , entonces el servidor X considera 0x37la tecla que produce el código clave una tecla Mayús.0x37
El servidor X mantiene las listas de asignaciones de modificadores, pero cada cliente puede cambiarlas. Por ejemplo, un cliente puede solicitar que se agregue la " tecla F1 " a la lista de modificadores "Shift". A partir de este momento, esta tecla se comporta como otro modificador de turno. Sin embargo, el código clave correspondiente a F1 aún se genera cuando se presiona esta tecla. Como resultado, F1 funciona como lo hacía antes (por ejemplo, se puede abrir una ventana de ayuda cuando se presiona), pero también funciona como la tecla Mayús (presionar "a" en un editor de texto mientras F1 está presionado agrega "A" al texto actual).
El servidor X mantiene y utiliza una asignación de modificadores para los botones del mouse. Sin embargo, los botones sólo se pueden permutar . Esto es especialmente útil para intercambiar el botón más a la izquierda y el más a la derecha para usuarios zurdos .
El xmodmapprograma muestra y cambia las asignaciones de teclas, modificadores y botones del mouse.
Una captura es una condición en la que todos los eventos del teclado o del mouse se envían a un solo cliente. Un cliente puede solicitar que se le quite el teclado, el mouse o ambos: si el servidor cumple la solicitud, todos los eventos de teclado/ratón se envían al cliente que lo toma hasta que se libera el agarre. Los demás clientes no recibirán estos eventos.
Al solicitar una captura, un cliente especifica una ventana de captura : todos los eventos se envían al cliente de captura como si fueran relativos a la ventana de captura. Sin embargo, los otros clientes no reciben eventos incluso si los han seleccionado en la ventana de captura. Hay dos tipos de capturas:
Un cliente puede establecer un control sobre el teclado, el puntero o ambos. Una solicitud de captura puede incluir una solicitud de congelar el teclado o el puntero. La diferencia entre capturar y congelar es que capturar cambia el destinatario de los eventos, mientras que congelar detiene su entrega por completo. Cuando un dispositivo se congela, los eventos que genera se almacenan en una cola para entregarse como de costumbre cuando finaliza la congelación.
Para los eventos de puntero, un parámetro adicional afecta la entrega de eventos: una máscara de evento, que especifica qué tipos de eventos se entregarán y cuáles se descartarán.
Las solicitudes de captura incluyen un campo para especificar qué sucede con los eventos que se enviarían al cliente de captura incluso si no hubiera establecido la captura. En particular, el cliente puede solicitar que se envíen como de costumbre o según el pedido. Estas dos condiciones no son lo mismo como pueden parecer. Por ejemplo, un cliente que normalmente recibiría los eventos del teclado en una primera ventana puede solicitar que una segunda ventana tome el teclado. Los eventos que normalmente se enviarían a la primera ventana pueden redirigirse o no a la ventana de captura dependiendo del parámetro en la solicitud de captura.
Un cliente también puede solicitar la captura de todo el servidor. En este caso, el servidor no procesará ninguna solicitud excepto las que provengan del cliente agarrador.
Existen otras solicitudes y eventos en el protocolo central. El primer tipo de solicitudes es relativo a la relación principal entre ventanas: un cliente puede solicitar cambiar el padre de una ventana o puede solicitar información sobre la paternidad de Windows. Otras solicitudes están relacionadas con la selección , que sin embargo se rige en su mayor parte por otros protocolos. Otras solicitudes son sobre el foco de entrada y la forma del puntero . Un cliente también puede solicitar que se elimine al propietario de un recurso (ventana, mapa de píxeles, etc.), lo que hace que el servidor finalice la conexión con él. Finalmente, un cliente puede enviar una solicitud de no operación al servidor.
El protocolo central de X Window fue diseñado para ser extensible. El protocolo central especifica un mecanismo para consultar las extensiones disponibles y cómo se realizan las solicitudes de extensión, los eventos y los paquetes de errores.
En particular, un cliente puede solicitar la lista de todas las extensiones disponibles para obtener datos relativos a una extensión específica. Los paquetes de extensiones son similares a los paquetes del protocolo central. El protocolo central especifica que los paquetes de solicitud, evento y error contienen un número entero que indica su tipo (por ejemplo, la solicitud para crear una nueva ventana tiene el número 1). Un rango de estos números enteros está reservado para extensiones.
Cuando el cliente establece inicialmente una conexión con el servidor, el servidor puede responder aceptando la conexión, rechazándola o solicitando autenticación . Una solicitud de autenticación contiene el nombre del método de autenticación que se utilizará. El protocolo central no especifica el proceso de autenticación, que depende del tipo de autenticación utilizado, salvo que finaliza cuando el servidor envía un paquete de aceptación o de rechazo.
Durante la interacción normal entre un cliente y un servidor, las únicas solicitudes relacionadas con la autenticación son sobre el método de acceso basado en host . En particular, un cliente puede solicitar que se habilite este método y puede solicitar leer y cambiar la lista de hosts ( clientes ) que están autorizados a conectarse. Las aplicaciones típicas no utilizan estas solicitudes; El programa los utiliza xhostpara otorgarle a un usuario o script acceso a la lista de acceso del host. El método de acceso basado en host se considera inseguro.
La mayoría de los programas cliente se comunican con el servidor a través de la biblioteca cliente Xlib . En particular, la mayoría de los clientes utilizan bibliotecas como Xaw , Motif , GTK+ o Qt que a su vez utilizan Xlib para interactuar con el servidor. El uso de Xlib tiene los siguientes efectos:
XFlush;XGetWindowAttributes;XNextEvent) y la llamada se bloquea (por ejemplo, XNextEventse bloquea si la cola está vacía).Las bibliotecas de nivel superior como Xt (que a su vez utilizan Xaw y Motif ) permiten que el programa cliente especifique las funciones de devolución de llamada asociadas con algunos eventos; la biblioteca se encarga de sondear la cola de eventos y llamar a la función apropiada cuando sea necesario; Algunos eventos, como aquellos que indican la necesidad de volver a dibujar una ventana, son manejados internamente por Xt.
Las bibliotecas de nivel inferior, como XCB , proporcionan acceso asincrónico al protocolo, lo que permite ocultar mejor la latencia.
El protocolo central del sistema X Window no exige la comunicación entre clientes y no especifica cómo se utilizan las ventanas para formar los elementos visuales que son comunes en las interfaces gráficas de usuario ( botones , menús , etc.). Los elementos de la interfaz gráfica de usuario están definidos por bibliotecas cliente que realizan kits de herramientas de widgets . La comunicación entre clientes está cubierta por otros estándares, como ICCCM y las especificaciones de freedesktop . [10]
La comunicación entre clientes es relevante para las selecciones, cortar búferes y arrastrar y soltar , que son los métodos utilizados por un usuario para transferir datos de una ventana a otra. Dado que las ventanas pueden estar controladas por diferentes programas, es necesario un protocolo para intercambiar estos datos. La comunicación entre clientes también es relevante para los administradores de ventanas X , que son programas que controlan la apariencia de las ventanas y la apariencia general de la interfaz gráfica de usuario.
Otro tema más en el que la comunicación entre clientes es hasta cierto punto relevante es el de la gestión de sesiones .
La forma en que se inicia una sesión de usuario es otra cuestión que no está cubierta por el protocolo central. Por lo general, esto lo hace automáticamente el administrador de pantalla X. Sin embargo, el usuario también puede iniciar una sesión manualmente ejecutando los programas xinit o startx .