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 que se utiliza 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 solo servidor controla el hardware de entrada / salida , como la pantalla , el teclado y el mouse ; todos los programas de aplicaciónactuar como clientes , interactuando con el usuario y con el resto de 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 construidos en la parte superior del protocolo central del sistema X Window o como protocolos separados.
En el protocolo central del sistema X Window, solo 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 las 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. Los eventos son enviados por el servidor para notificar a los clientes sobre la actividad del usuario u otras ocurrencias que les interesan. Los errores son paquetes enviados por el servidor para notificar a un cliente sobre errores ocurridos durante el procesamiento de sus solicitudes. Las solicitudes pueden generar respuestas, eventos y errores; Aparte de esto, el protocolo no impone 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 un mecanismo, no una política". 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 independientes, [4] como las especificaciones ICCCM y freedesktop.org , y normalmente se aplican automáticamente mediante el uso de un conjunto de widgets determinado .
Descripción general
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 (en el protocolo no se especifica cómo se inicia el cliente). 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 enviando un paquete indicando la aceptación o rechazo de la conexión, o con una solicitud de autenticación adicional . 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:
- Solicitud: el cliente solicita información al servidor o lo solicita para realizar una acción.
- Responder: el servidor responde a una solicitud. No todas las solicitudes generan respuestas.
- Evento: el servidor informa al cliente de un evento, como una entrada de teclado o mouse, una ventana que se mueve, cambia de tamaño o se expone, etc.
- Error: el servidor envía un paquete de error si una solicitud no es válida. Dado que las solicitudes están en cola, es posible que los paquetes de error generados por una solicitud no se envíen inmediatamente.
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 hay. También se incluyen en los 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.
Ventanas
Lo que generalmente se denomina ventana en la mayoría de las interfaces gráficas de usuario se denomina ventana de nivel superior en el sistema X Window. El término ventana también se usa para denotar 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 subventanas directa o indirectamente 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 a lo largo del tiempo. En particular, el contenido de la ventana puede destruirse cuando la ventana se mueve, cambia de tamaño, se cubre con otras ventanas y, en general, se hace total o parcialmente invisible. En particular, el contenido se pierde si el servidor X no mantiene un almacenamiento de respaldo del contenido de la ventana. El cliente puede solicitar una tienda de respaldo para mantener una ventana, pero el servidor no tiene la obligación de hacerlo. Por lo tanto, los clientes no pueden asumir que se mantiene la tienda 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 asociados , 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 InputOutput
o InputOnly
. InputOutput
Las ventanas se pueden mostrar en la pantalla y se utilizan para dibujar. InputOnly
Las ventanas nunca se muestran en la pantalla y se utilizan solo para recibir entradas.
El marco decorativo y la barra de título (posiblemente incluidos los botones) que normalmente 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 la entrada relacionada 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 generalmente operan en la ventana que crearon sin tener en cuenta los cambios operados por el administrador de ventanas. Un cambio que debe tener en cuenta es que los administradores de ventanas de re-parentalidad , 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 las otras aplicaciones.
Los datos sobre una ventana se pueden obtener ejecutando el xwininfo
programa. Pasándole el argumento de la -tree
línea de comandos, este programa muestra el árbol de subventanas de una ventana, junto con sus identificadores y datos geométricos.
Pixmaps y dibujables
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 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 los mapas de píxeles se denominan de forma colectiva elementos de diseño y sus datos de contenido residen en el servidor. Sin embargo, un cliente puede solicitar que el contenido de un dibujo se transfiera del servidor al cliente o viceversa.
Contextos gráficos y fuentes
El cliente puede solicitar una serie de operaciones gráficas, como despejar un área, copiar un área en otra, dibujar puntos, líneas, rectángulos y texto. Además de la limpieza, todas las operaciones son posibles en todos los elementos de diseño, 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 mediante 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 lo ha hecho) o descargue una fuente (si no la utilizan otros clientes). 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.
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 de acuerdo con sus atributos. Estas convenciones también especifican los valores de las propiedades opcionales que se pueden adjuntar a las fuentes.
El xlsfonts
programa imprime la lista de fuentes almacenadas en el servidor. El xfontsel
programa 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 apoyo de las bibliotecas Xft o cairo y la extensión XRender . No se proporciona ninguna especificación sobre las fuentes del lado del cliente en el protocolo principal.
Recursos e identificadores
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 usa como nombres para ellos 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 identificador puede ser utilizado posteriormente por el cliente 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:
Window
Pixmap
Font
Colormap
(una tabla de colores, que se describe a continuación)Graphic context
Estos objetos se denominan 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 tanto los atributos de la ventana (padre, ancho, alto, etc.) como 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 usar para crear nuevos recursos. El servidor especifica este conjunto como dos números enteros incluidos en el paquete de aceptación (el paquete que envía al cliente para informarle que la conexión es aceptada). Los clientes eligen identificadores que están en este conjunto de tal manera que no chocan: dos objetos entre ventanas, mapas de píxeles, fuentes, mapas de color 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 al 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 únicos para el servidor, no solo para el cliente; por ejemplo, no hay dos ventanas que tengan el mismo identificador, incluso si son 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 hacer referencia al mismo recurso. Por ejemplo, si un cliente crea una ventana de identificador 0x1e00021
y pasa este número 0x1e00021
a otra aplicación (a través de cualquier medio disponible, por ejemplo, almacenando este número en un archivo que también es accesible para la otra aplicación), esta otra aplicación puede funcionar. en la misma ventana. Esta posibilidad es, por ejemplo, explotada 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.
Eventos
Los eventos son paquetes enviados por el servidor a un cliente para comunicar que ha sucedido algo en lo que el cliente puede estar interesado. Por ejemplo, un evento se envía cuando el usuario presiona una tecla o hace clic en un botón del mouse. Los eventos no solo se utilizan para la 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 que está seleccionado actualmente: este evento se envía al cliente que está manejando actualmente la ventana que contiene la selección.
El Expose
evento se envía cuando se hace visible un área de una ventana de contenido destruido. El contenido de una ventana puede destruirse en algunas condiciones, por ejemplo, si la ventana está cubierta y el servidor no mantiene una tienda de respaldo. El servidor genera un Expose
evento para notificar al cliente que se debe dibujar una parte de la ventana.
La mayoría de los tipos de eventos se envían solo si el cliente expresó previamente su interés en ellos. Esto se debe a que los clientes solo pueden estar interesados en algún tipo de eventos. Por ejemplo, un cliente puede estar interesado en eventos relacionados con el teclado pero no con los 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é tipo de eventos quieren que se envíen estableciendo un atributo de una ventana. Por ejemplo, para volver a dibujar una ventana cuando su contenido ha sido destruido, un cliente debe recibir los Expose
eventos, que le informan que la ventana debe volver a dibujarse. Sin embargo, al cliente se le enviarán Expose
eventos solo si el cliente ha manifestado previamente su interés en estos eventos, lo cual se hace configurando apropiadamente el atributo de máscara de evento de la ventana.
Diferentes clientes pueden solicitar eventos en la misma ventana. Incluso pueden establecer 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 puede seleccionar un cliente a la vez para cada ventana. En particular, estos eventos informan los clics del botón del mouse y algunos cambios relacionados con la administración de ventanas.
El xev
programa muestra los eventos relacionados con una ventana. En particular, xev -id WID
solicita todos los eventos posibles relativos a la ventana de identificador WID
y los imprime.
Ejemplo
El siguiente es un posible ejemplo de interacción entre un servidor y un programa que crea una ventana con un recuadro 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 pueden generar errores.
- El cliente abre la conexión con el servidor y envía el paquete inicial especificando el orden de bytes que está usando.
- El servidor acepta la conexión (no hay autorización involucrada en este ejemplo) enviando un paquete apropiado, que contiene otra información como el identificador de la ventana raíz (por ejemplo,
0x0000002b
) y qué identificadores puede crear el cliente. - El cliente solicita la creación de un contexto gráfico predeterminado con identificador
0x00200000
(esta solicitud, como las otras solicitudes de este ejemplo, no genera respuestas desde el servidor) - El cliente solicita al servidor que cree una ventana de nivel superior (es decir, especifica que el padre sea la ventana raíz
0x0000002b
) con identificador0x00200001
, tamaño 200x200, posición (10,10), etc. - El cliente solicita un cambio en los atributos de la ventana
0x00200001
, especificando que está interesado en recibirExpose
yKeyPress
eventos. - El cliente solicita que se mapee la ventana
0x00200001
(se muestra en la pantalla) - Cuando la ventana se hace visible y se debe dibujar su contenido, el servidor envía al cliente un
Expose
evento - En respuesta a este evento, el cliente solicita que se dibuje un cuadro enviando una
PolyFillRectangle
solicitud con ventana0x00200001
y contexto gráfico.0x00200000
Si la ventana está cubierta por otra ventana y se descubre nuevamente, asumiendo que no se mantiene la tienda de respaldo:
- El servidor envía otro
Expose
evento para decirle al cliente que la ventana debe dibujarse nuevamente - El cliente vuelve a dibujar la ventana enviando una
PolyFillRectangle
solicitud
Si se presiona una tecla:
- El servidor envía un
KeyPress
evento al cliente para notificarle que el usuario ha presionado una tecla - El cliente reacciona de forma adecuada (en este caso, termina)
Colores
A nivel de protocolo, un color se representa mediante un entero sin signo de 32 bits, denominado valor de píxel . Los siguientes elementos afectan la representación de colores:
- la profundidad del color
- el mapa de colores , que es una tabla que contiene valores de intensidad de rojo, verde y azul
- el tipo visual , que especifica cómo se usa la tabla para representar colores
En el caso más fácil, el mapa de colores es una tabla que contiene un triple RGB en cada fila. Un valor de píxel x
representa el color contenido en la x
-ésima fila de la tabla. Si el cliente puede cambiar las entradas en el mapa de colores, esta representación es identificada por la PseudoColor
clase visual . La clase visual StaticColor
es 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. PseudoColor
y StaticColor
son dos. Otros dos son GrayScale
y StaticGray
, que se diferencian en que solo muestran tonos de gris.
Las dos clases visuales restantes difieren de las anteriores porque dividen los valores de los píxeles en tres partes y usan tres tablas separadas para la intensidad del 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:
- el valor de píxel se ve como una secuencia de bits
- esta secuencia se divide en tres partes
- Cada uno de estos tres fragmentos de bits se considera un número entero y se utiliza como índice para encontrar un valor en cada una de las tres tablas independientes.
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 el triple de los valores de intensidad. Las clases visuales que utilizan esta representación son las DirectColor
y TrueColor
, que se diferencian en si el cliente puede cambiar los mapas de color 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 la representación de colores. Cada servidor tiene un conjunto fijo de tipos visuales, cada uno asociado con un identificador numérico. Estos 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 la conexión de un cliente, el paquete de aceptación enviado por el servidor contiene una secuencia de bloques, cada uno con información sobre una sola pantalla. Para cada pantalla, el bloque relativo contiene una lista de otros bloques, cada uno relativo a una profundidad de color específica que es compatible con la pantalla. Para cada profundidad admitida, esta lista contiene una lista de tipos visuales. Como resultado, a cada pantalla se le asocia una cantidad de posibles profundidades, y a cada profundidad de cada pantalla se le asocia una cantidad de posibles tipos visuales. Un tipo de visual dado 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 para la 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 usan mapas de colores incluso si el hardware no usa una paleta. Siempre que el hardware utiliza paletas, solo se puede instalar un número limitado de mapas de color. En particular, se instala un mapa de colores cuando el hardware muestra los colores de acuerdo con é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 usan el mapa de colores desinstalado no se muestran con el color correcto, un efecto llamado color intermitente o tecnicolor . Este problema se puede resolver utilizando mapas de color estándar , que son mapas de color con una asociación predecible entre los valores de los píxeles y los colores. Gracias a esta propiedad, diferentes aplicaciones pueden utilizar mapas de color estándar.
La creación de mapas de color está regulada por la convención ICCCM . Los mapas de color 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 Release 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 del 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 los sistemas de color CIEXYZ , xyY , CIELUV y CIELAB y también con TekHVC . [1] , [2]
Átomos
Los átomos son números enteros de 32 bits que representan cadenas . Los diseñadores de protocolos 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 número entero de 32 bits. La brevedad de los átomos se aprovechó al exigir su uso en los tipos de paquetes que probablemente se envíen muchas veces con las mismas cadenas; esto da como resultado 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, a saber, 32 bytes: los paquetes de tamaño fijo pueden contener átomos, mientras que 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 de dos formas. Primero, los identificadores de átomos son elegidos por el servidor, no por 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, únicos. Sin embargo, un átomo y un identificador de recurso pueden coincidir. La cadena asociada con un átomo se llama el nombre del átomo . El nombre de un átomo no se puede cambiar después de la creación, y dos átomos no pueden 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 dados).
Los átomos se utilizan para varios propósitos, 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).
Propiedades
Cada ventana tiene un conjunto predefinido de atributos y un conjunto de propiedades, todos almacenados en el servidor y accesibles a los clientes a través de las solicitudes correspondientes. 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 ningún significado al 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 dado y almacenar un valor en ella. Las propiedades están asociadas a las ventanas: dos propiedades con el mismo nombre pueden existir en dos ventanas diferentes y tener diferentes tipos y valores.
El nombre, el tipo y el valor de una propiedad son cadenas; más precisamente, son átomos, es decir, cadenas almacenadas en el servidor y accesibles a los clientes mediante 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 suelen leer 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 freedesktop , [10] los administradores de ventanas deben almacenar el identificador de la ventana actualmente activa en la propiedad nombrada _NET_ACTIVE_WINDOW
de 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 diferentes computadoras.
El xprop
programa imprime las propiedades de una ventana determinada; xprop -root
imprime el nombre, tipo y valor de cada propiedad de la ventana raíz.
Mapeos
En el sistema X Window, a cada tecla física individual se le asocia un número en el rango de 8 a 255, llamado su código de tecla . Un código de clave solo 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. En su lugar, cada uno de estos caracteres o términos se identifica mediante un keyym . Si bien un código de tecla solo depende de la tecla real que se presiona, un símbolo de tecla 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 KeyPress
o KeyRelease
a los clientes apropiados. Estos eventos contienen:
- el código de la tecla presionada
- el estado actual de los modificadores (Shift, Control, etc.) y los botones del mouse
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 indica que se presionó una tecla determinada mientras el modificador Shift estaba desactivado. Si esta clave generaría normalmente el carácter "a", el cliente (y no el servidor) asocia este evento al carácter "A".
Si bien el cliente realiza la traducción de códigos clave a claves, 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 este mapeo y lo usan para decodificar el código de clave y el campo de modificadores de un evento clave en un keyym. Sin embargo, los clientes también pueden cambiar esta asignación 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 un máximo de ocho modificadores. Sin embargo, cada modificador se puede asociar con más de una tecla. 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 teclas 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 que son ese modificador. Por ejemplo, si la lista del primer modificador (el modificador "Shift") contiene el código de tecla 0x37
, 0x37
el servidor X considera que la tecla que produce el código de tecla es una tecla de mayúsculas.
El servidor X mantiene las listas de asignaciones de modificadores, pero todos los clientes pueden cambiarlas. Por ejemplo, un cliente puede solicitar que se agregue la " tecla F1 " a la lista de modificadores de "Shift". A partir de este momento, esta tecla se comporta como otro modificador de turno. Sin embargo, el código de tecla correspondiente a F1 todavía se genera cuando se presiona esta tecla. Como resultado, F1 funciona como antes (por ejemplo, se puede abrir una ventana de ayuda cuando se presiona), pero también funciona como la tecla de mayúsculas (presionar "a" en un editor de texto mientras F1 está abajo agrega "A" al texto actual).
El servidor X mantiene y usa una asignación de modificadores para los botones del mouse. Sin embargo, los botones solo se pueden permutar . Esto es principalmente útil para intercambiar el botón más a la izquierda y el más a la derecha para usuarios zurdos .
El xmodmap
programa muestra y cambia las asignaciones de teclas, modificadores y botones del mouse.
Agarra
Una captura es una condición en la que todos los eventos de teclado o mouse se envían a un solo cliente. Un cliente puede solicitar una captura del teclado, el mouse o ambos: si el servidor cumple la solicitud, todos los eventos de teclado / mouse se envían al cliente de captura hasta que se suelta la captura. Los otros 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 agarres:
- activo: el agarre se realiza inmediatamente
- pasivo: el agarre se lleva a cabo solo cuando se presiona una tecla o botón del mouse previamente especificado y termina cuando se suelta
Un cliente puede establecer un agarre sobre el teclado, el puntero o ambos. Una solicitud de captura puede incluir una solicitud para congelar el teclado o el puntero. La diferencia entre agarrar y congelar es que agarrar cambia el destinatario de los eventos, mientras que congelar detiene su entrega por completo. Cuando un dispositivo está congelado, los eventos que genera se almacenan en una cola para ser entregados 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 agarre. Estas dos condiciones no son las mismas que pueden parecer. Por ejemplo, un cliente que normalmente recibiría los eventos del teclado en una primera ventana puede solicitar que el teclado sea capturado por una segunda ventana. Los eventos que normalmente se enviarían a la primera ventana pueden o no ser redirigidos a la ventana de captura según el 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 de captura.
Otro
Existen otras solicitudes y eventos en el protocolo central. El primer tipo de solicitudes está relacionado con 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 las ventanas. Otras solicitudes están relacionadas con la selección , que, sin embargo, se rige principalmente por otros protocolos. Otras solicitudes se refieren al 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 termine la conexión con él. Finalmente, un cliente puede enviar una solicitud de no operación al servidor.
Extensiones
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 los 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.
Autorización
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 utilizada, aparte de que termina con el servidor enviando un paquete de aceptación o rechazo.
Durante la interacción regular entre un cliente y un servidor, las únicas solicitudes relacionadas con la autenticación se refieren al método de acceso basado en host . En particular, un cliente puede solicitar que se habilite este método y puede solicitar la lectura y el cambio de la lista de hosts ( clientes ) que están autorizados a conectarse. Las aplicaciones típicas no utilizan estas solicitudes; El xhost
programa los utiliza para dar acceso a un usuario o un script a la lista de acceso de host. El método de acceso basado en host se considera inseguro.
Xlib y otras bibliotecas cliente
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 usan bibliotecas como Xaw , Motif , GTK + o Qt que, a su vez, usan Xlib para interactuar con el servidor. El uso de Xlib tiene los siguientes efectos:
- Xlib sincroniza al cliente con respecto a las respuestas y eventos:
- las funciones de Xlib que envían solicitudes se bloquean hasta que se reciben las respuestas adecuadas, si se espera alguna; en otras palabras, un cliente X Window que no usa Xlib puede enviar una solicitud al servidor y luego realizar otras operaciones mientras espera la respuesta, pero un cliente que usa Xlib solo puede llamar a una función Xlib que envía la solicitud y espera la respuesta. bloqueando así al cliente mientras espera la respuesta (a menos que el cliente inicie un nuevo hilo antes de llamar a la función);
- mientras que el servidor envía eventos de forma asincrónica , Xlib almacena los eventos recibidos por el cliente en una cola ; el programa cliente solo puede acceder a ellos llamando explícitamente a funciones de la biblioteca X11; en otras palabras, el cliente se ve obligado a bloquear o esperar ocupado si espera un evento.
- Xlib no envía solicitudes al servidor inmediatamente, sino que las almacena en una cola, llamada búfer de salida ; las solicitudes en el búfer de salida se envían realmente cuando:
- el programa lo solicita explícitamente llamando a una función de biblioteca como
XFlush
; - el programa llama a una función que da como resultado algo que implica una respuesta del servidor, como
XGetWindowAttributes
; - el programa solicita un evento en la cola de eventos (por ejemplo, llamando
XNextEvent
) y la llamada se bloquea (por ejemplo, seXNextEvent
bloquea si la cola está vacía).
- el programa lo solicita explícitamente llamando a una función de biblioteca como
Las bibliotecas de nivel superior como Xt (que a su vez es utilizada por Xaw y Motif ) permiten al programa cliente especificar 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 adecuada cuando sea necesario; algunos eventos, como los 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 una mejor ocultación de la latencia.
Partes no especificadas
El protocolo central del sistema X Window no impone 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 se definen mediante bibliotecas cliente que realizan kits de herramientas de widgets . La comunicación entre clientes está cubierta por otros estándares como ICCCM y especificaciones de escritorio libre . [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 el aspecto general de la interfaz gráfica de usuario. Otro tema en el que la comunicación entre clientes es hasta cierto punto relevante es el de la gestión de sesiones .
Cómo se inicia una sesión de usuario es otro tema que no está cubierto por el protocolo central. Por lo general, esto se hace automáticamente por el gestor de pantalla X . Sin embargo, el usuario también puede iniciar una sesión manualmente ejecutando los programas xinit o startx .
Ver también
- Protocolos y arquitectura del sistema X Window
- Xlib
- Intrínsecos
- Xnee se puede utilizar para olfatear el protocolo del sistema X Window
Referencias
- ^ Robert W. Scheifler y James Gettys: X Window System: protocolos de núcleo y extensión, X versión 11, versiones 6 y 6.1 , Digital Press 1996, ISBN 1-55558-148-X
- ^ RFC 1013
- ^ Grant Edwards. Introducción a las interfaces de usuario X11
- ^ Jim Gettys. Hoja de ruta de la tecnología de escritorio de código abierto Archivado el 2 de enero de 2006 en la Wayback Machine.
- ^ "Preguntas frecuentes de comp.fonts: X11 Info" . www.faqs.org .
- ^ Jim Flowers; Stephen Gildea (1994). "X Convenciones de descripción de fuentes lógicas" (PDF) . Corporación de Equipos Digitales . X Consorcio . Archivado desde el original (PDF) el 28 de marzo de 2005 . Consultado el 30 de diciembre de 2005 .
- ^ Matthieu Herrb y Matthias Hopf. Nuevas evoluciones en el sistema X Window .
- ^ "Interfaz con ghostscript - Manual GNU gv" . www.gnu.org .
- ^ David Rosenthal . Manual de convenciones de comunicación entre clientes . Estándar del Consorcio MIT X, 1989
- ^ a b "wm-spec" . www.freedesktop.org .
enlaces externos
- Fundación X.Org (página de inicio oficial): espejo con el nombre de dominio 'freedesktop.org'.
- Partes internas del sistema X Window
- Páginas de Kenton Lee sobre X Window y Motif
- Protocolo del sistema X Window, versión 11 (versión actual)