b'\n_START_ARTICLE_\nProtocolo base de X Window System\n_START_PARAGRAPH_\nEl Protocolo base del sistema X Window\xe2\x80\x8b\xe2\x80\x8b\xe2\x80\x8b es la base del protocolo de X Window System, un sistema de ventanas de red que muestra bitmaps y que permite construir interfaces gr\xc3\xa1ficas de usuarios en Unix, Unix-Like y otros sistemas operativos. El sistema de de ventanas X Window est\xc3\xa1 basado en un modelo de Cliente-Servidor: un solo servidor controla los dispositivos hardware de entrada-salida, como el monitor, el teclado, y el rat\xc3\xb3n; todos los programas de la aplicaci\xc3\xb3n act\xc3\xbaan como un solo cliente, interactuando con el usuario. Esta interacci\xc3\xb3n es regulada por el protocolo del base del sistema de ventanas X Window.\xe2\x80\x8b Existen otros protocolos relacionados con el sistema X Window, algunos utilizados en las capas superiores del protocolo X Window y otros como protocolos independientes._NEWLINE_En el protocolo base de X Window System, s\xc3\xb3lo cuatro clases de paquetes son enviadas, as\xc3\xadncronamente, sobre la red: peticiones, respuestas, los acontecimientos, y los errores. Las \xe2\x80\x9cpeticiones\xe2\x80\x9d son enviadas por un cliente al server para preguntar si puede mejorar alguna aplicaci\xc3\xb3n (por ejemplo crear una nueva ventana) y adem\xc3\xa1s son devueltos a la persona que los envi\xc3\xb3 para que reciba los datos (Repuestas). Las \xe2\x80\x9crespuestas\xe2\x80\x9d son enviadas por un cliente para confirmar alg\xc3\xban dato. Los \xe2\x80\x9ceventos\xe2\x80\x9d son enviados por un usuario para notificar a otros de que hay alguna junta de inter\xc3\xa9s o trabajo. Los \xe2\x80\x9cerrores\xe2\x80\x9d son enviados al usuario para notificar que ha ocurrido un error durante el proceso de peticiones. En las peticiones pueden generarse respuestas, eventos y errores; u otros, el protocolo manda una orden espec\xc3\xadfica para que el usuario no mande la petici\xc3\xb3n por otra red. Algunas extensiones a el protocolo core existente, cada una con sus propias peticiones, respuestas, eventos y errores._NEWLINE_X se origin\xc3\xb3 en el Instituto Tecnol\xc3\xb3gico de Massachusetts en 1984 (su liberaci\xc3\xb3n X11 actual apareci\xc3\xb3 en septiembre 1987). Fue dise\xc3\xb1ado por Bob Scheifer y Jim Gettys, pusieron como principio primordial del proyecto \xe2\x80\x9cCrearemos un mecanismo, no una pol\xc3\xadtica\xe2\x80\x9d. Como resultado, el protocolo core no espec\xc3\xadfica la interacci\xc3\xb3n entre clientes y entre un cliente y el usuario. Estas interacciones est\xc3\xa1n sujetas por especificaciones separadas,\xe2\x80\x8b como el ICCCM y la freedesktop.org especificaciones. Son t\xc3\xadpicamente autom\xc3\xa1ticos, hasta usando un dado Widget toolkit.\n_START_SECTION_\nVentanas\n_START_PARAGRAPH_\nLo que es usualmente llamado "ventana" en la mayor\xc3\xada de las interfaces gr\xc3\xa1ficas de usuarios, en el X Window System se llama "ventana de nivel superior" (top-level window). El t\xc3\xa9rmino ventana tambi\xc3\xa9n es usado para denotar las ventanas que descansan dentro de otra ventana, es decir, subventanas de una ventana padre. Los elementos gr\xc3\xa1ficos tales como los botones, men\xc3\xbaes, iconos, etc. pueden ser creados usando subventanas._NEWLINE_Un cliente puede solicitar la creaci\xc3\xb3n de una ventana. M\xc3\xa1s precisamente, puede solicitar la creaci\xc3\xb3n de una subventana para una ventana existente. Como resultado, las ventanas creadas por los clientes se arreglan en forma de un \xc3\xa1rbol (una jerarqu\xc3\xada). La ra\xc3\xadz de este \xc3\xa1rbol es la ventana ra\xc3\xadz, que es una ventana especial creada autom\xc3\xa1ticamente por el servidor en el arranque. Todas las otras ventanas son directa o indirectamente subventanas de la ventana ra\xc3\xadz. Las ventanas de nivel superior son las subventanas directas de la ventana ra\xc3\xadz. Visiblemente, la ventana ra\xc3\xadz es tan grande como la pantalla, y descansa detr\xc3\xa1s del resto de las ventanas. Sin embargo la ventana ra\xc3\xadz puede ser m\xc3\xa1s grande que la pantalla, en este caso el usuario puede desplazarse alrededor del \xc3\xa1rea visible._NEWLINE_No se garantiza que el contenido de una ventana siempre sea preservado en el tiempo. Particularmente, el contenido de la ventana puede ser destruido cuando la ventana es movida, redimensionada, cubierta por otras ventanas, y en general, hecha no visible total o parcialmente. En particular, el contenido es perdido si el servidor X no est\xc3\xa1 manteniendo un almacenamiento de respaldo del contenido de la ventana. El cliente puede solicitar memoria de respaldo para que una ventana sea mantenida, pero no hay obligaci\xc3\xb3n para que el servidor lo haga. Por lo tanto, los clientes no pueden asumir que el almacenamiento de respaldo sea mantenido. Si una parte visible de una ventana tiene un contenido sin especificar, un evento es enviado para notificar al cliente que el contenido de la ventana tiene que ser dibujado otra vez._NEWLINE_Cada ventana tiene un conjunto asociado de atributos, tales como la geometr\xc3\xada de la ventana (tama\xc3\xb1o y posici\xc3\xb3n), la imagen de fondo, si la memoria de respaldo para ella se ha pedido o no, etc. El protocolo incluye las peticiones necesarias para que un cliente pueda inspeccionar y cambiar los atributos de una ventana._NEWLINE_Las ventanas pueden ser de InputOutput (entrada-salida) o de InputOnly (solo-entrada). Las ventanas que pueden ser mostradas en la pantalla y son usadas para dibujar contenido son de la primera clase. La segunda clase de ventanas nunca son mostradas en la pantalla; son usadas solo para recibir la entrada._NEWLINE_El marco decorativo y la barra de t\xc3\xadtulo (posiblemente incluyendo botones) que son usualmente vistos alrededor de las ventanas, son creados por el manejador de ventanas, no por el cliente que crea la ventana. El manejador de ventanas tambi\xc3\xa9n maneja la entrada relacionada con estos elementos, tales como redimensionar la ventana cuando el usuario hace click y arrastra el marco de ventana. Los clientes usualmente operan en la ventana que ellos crearon sin hacer caso de los cambios operados por el manejador de ventanas. Un cambio que tiene que tomar en cuenta el Re-parenting window manager, que casi todos los manejadores de ventanas modernos son, es cambiar la ventana de nivel superior a una ventana que no sea la ra\xc3\xadz. Desde el punto de vista del protocolo base, el manejador de ventanas es un cliente, no diferente de otras aplicaciones._NEWLINE_Los datos acerca de una ventana pueden ser obtenidos corriendo el programa xwininfo. Pas\xc3\xa1ndole el argumento de l\xc3\xadnea de comando -tree, este programa muestra el \xc3\xa1rbol de subventanas de una ventana, junto con sus identificadores y datos de geometr\xc3\xada.\n_START_SECTION_\nPixmaps y drawables\n_START_PARAGRAPH_\nUn pixmap es una regi\xc3\xb3n de memoria que puede ser usada para dibujo (drawing) de contenido. A diferencia de las ventanas, los pixmaps no se muestran autom\xc3\xa1ticamente en la pantalla. Sin embargo, el contenido de un pixmap (o una parte de \xc3\xa9l) puede ser transferido a una ventana y viceversa. Esto permite t\xc3\xa9cnicas tales como double buffering. La mayor\xc3\xada de las operaciones gr\xc3\xa1ficas que se pueden hacer en ventanas, tambi\xc3\xa9n se pueden hacer en pixmaps._NEWLINE_Las ventanas y los pixmaps son colectivamente llamados drawables (dibujables), y sus contenidos de datos residen en el servidor. Sin embargo, un cliente puede solicitar que el contenido de un drawable sea transferido del servidor al cliente o viceversa.\n_START_SECTION_\nLos contextos gr\xc3\xa1ficos y las fuentes\n_START_PARAGRAPH_\nEl cliente puede pedir un n\xc3\xbamero de operaciones gr\xc3\xa1ficas, tales como limpiar un \xc3\xa1rea, copiar un \xc3\xa1rea en otra, dibujar puntos, l\xc3\xadneas, rect\xc3\xa1ngulos, y texto. A menos que se diga lo contrario, todas las operaciones son posibles en todos los drawables, tanto en las ventanas como en los pixmaps._NEWLINE_La mayor\xc3\xada de los pedidos de operaciones gr\xc3\xa1ficas incluyen un contexto gr\xc3\xa1fico, que es una estructura que contiene los par\xc3\xa1metros de las operaciones gr\xc3\xa1ficas. Un contexto gr\xc3\xa1fico incluye el color del primero plano, el color del fondo, la fuente del texto, y otros par\xc3\xa1metros gr\xc3\xa1ficos. Cuando se pide una operaci\xc3\xb3n gr\xc3\xa1fica, el cliente incluye un contexto gr\xc3\xa1fico. No todos los par\xc3\xa1metros del contexto gr\xc3\xa1fico afectan a la operaci\xc3\xb3n: por ejemplo, la fuente no tiene efecto al dibujar una l\xc3\xadnea._NEWLINE_El protocolo base espec\xc3\xadfica el uso de las fuentes del lado del servidor.\xe2\x80\x8b Tales fuentes son almacenadas como archivos, y el servidor tiene acceso directamente v\xc3\xada el sistema de archivos local o v\xc3\xada la red desde otro programa llamado servidor de fuente. Los clientes pueden pedir la lista de fuentes disponibles al servidor y pueden solicitar que una fuente sea cargada (si ya no lo est\xc3\xa1) o descargarla del servidor (si no es usada por otros clientes). Un cliente puede pedir la informaci\xc3\xb3n de car\xc3\xa1cter general sobre una fuente (por ejemplo, la "subida" (ascent) de la fuente) y el espacio que una espec\xc3\xadfica secuencia de caracteres (string) toma cuando es dibujada con una fuente determinada._NEWLINE_Los nombres de las fuentes son arbitrarias secuencias de caracteres (strings) en el nivel del Protocolo base de X Window. Las convenciones del X logical font description\xe2\x80\x8b especifican c\xc3\xb3mo las fuentes deben ser nombradas de acuerdo a sus atributos. Estas convenciones tambi\xc3\xa9n especifican los valores de las propiedades opcionales que pueden estar adjuntas a las fuentes._NEWLINE_El programa xlsfonts imprime la lista de fuentes almacenadas en el servidor. El programa xfontsel demuestra los glyphs de las fuentes, y permite al usuario seleccionar el nombre de una fuente para pegarla en otra ventana._NEWLINE_Actualmente se considera desaprobado el uso de las fuentes del lado del servidor a favor de las fuentes del lado del cliente.\xe2\x80\x8b Tales fuentes son renderizadas por el cliente, no por el servidor, con el soporte de las bibliotecas de Xft o de las bibliotecas Cairo y de la extensi\xc3\xb3n de XRender. En el protocolo de base, no hay especificaci\xc3\xb3nse acerca de fuentes del lado del cliente.\n_START_SECTION_\nEventos\n_START_PARAGRAPH_\nLos 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 es enviado cuando el usuario pulsa una tecla o hace click con el bot\xc3\xb3n del rat\xc3\xb3n. Los eventos no s\xc3\xb3lo son usados para la entrada: por ejemplo, los eventos son enviados para indicar la creaci\xc3\xb3n de nuevas subventanas en una ventana dada._NEWLINE_Cada evento es relativo a una ventana. Por ejemplo, si el usuario hace click cuando el puntero del rat\xc3\xb3n est\xc3\xa1 en una ventana, el evento ser\xc3\xa1 relativo a esa ventana. El paquete del evento contiene el identificador de esa ventana._NEWLINE_Un cliente puede solicitar al servidor que env\xc3\xade un evento a otro cliente; esto es usado para la comunicaci\xc3\xb3n entre los clientes. Tal evento es generado, por ejemplo, cuando un cliente solicita el texto que actualmente est\xc3\xa1 seleccionado: este evento es enviado al cliente que est\xc3\xa1 actualmente manejando la ventana que tiene la selecci\xc3\xb3n._NEWLINE_El evento Expose (exposici\xc3\xb3n) es enviado cuando se hace visible un \xc3\xa1rea de una ventana cuyo contenido se ha destruido. El contenido de una ventana puede ser destruido en algunas condiciones, por ejemplo, si la ventana es cubierta y el servidor no est\xc3\xa1 manteniendo un almacenamiento de respaldo. El servidor genera un evento Expose para notificar al cliente que una parte de la ventana tiene que ser redibujada._NEWLINE_La mayor\xc3\xada de los tipos de eventos son enviados solamente si el cliente previamente manifest\xc3\xb3 un inter\xc3\xa9s en ellos. Esto es porque los clientes pueden estar interesados solamente en una cierta clase de eventos. Por ejemplo, un cliente puede estar interesado en eventos relacionados con el teclado pero no en eventos relacionados con el rat\xc3\xb3n. Sin embargo, algunos tipos de eventos son enviados a los clientes incluso si no los han pedido espec\xc3\xadficamente._NEWLINE_Ajustando un atributo de una ventana, los clientes especifican qu\xc3\xa9 tipos de eventos quieren que se les env\xc3\xaden. Por ejemplo, para redibujar una ventana cuando su contenido se ha destruido, un cliente debe recibir los eventos Expose, que le informan que la ventana necesita ser redibujada otra vez. Sin embargo, al cliente se le enviar\xc3\xa1n los eventos Expose solamente si el cliente ha manifestado previamente su inter\xc3\xa9s en estos eventos, que es hecho apropiadamente ajustando el atributo de m\xc3\xa1scara del evento de la ventana._NEWLINE_Diferentes clientes pueden pedir eventos en la misma ventana. Pueden incluso ajustar diferentes m\xc3\xa1scaras de evento en la misma ventana. Por ejemplo, un cliente puede solamente pedir eventos del teclado en una ventana mientras que otro cliente pide solamente eventos del rat\xc3\xb3n en la misma ventana. Esto es posible porque, para cada ventana, el servidor mantiene una m\xc3\xa1scara de evento separada por cada cliente. Sin embargo, hay algunos tipos de eventos que pueden ser seleccionados solamente por un cliente a la vez para cada ventana. En particular, los eventos que reportan los click del bot\xc3\xb3n del rat\xc3\xb3n y algunos cambios relacionados al manejo de la ventana._NEWLINE_El programa xev muestra los eventos relativos a una ventana. En particular, xev -id WID pide todos los eventos posibles relativos a la ventana del identificador WID y los imprime.\n_START_SECTION_\n\xc3\x81tomos\n_START_PARAGRAPH_\nLos \xc3\xa1tomos son enteros de 32 bits representando strings. Los dise\xc3\xb1adores del protocolo introdujeron los \xc3\xa1tomos porque representan strings en un tama\xc3\xb1o corto y fijo:\xe2\x80\x8b mientras que un string puede ser arbitrariamente largo, un \xc3\xa1tomo es siempre un entero de 32 bits. La brevedad del \xc3\xa1tomo fue explotada asignando por mandato su uso en las clases de paquetes que son probables de ser enviados muchas veces con los mismos strings; esto resulta en un uso m\xc3\xa1s eficiente de la red. El de tama\xc3\xb1o fijo de los \xc3\xa1tomos fue explotado especificando un de tama\xc3\xb1o fijo para los eventos, nombrado 32 bytes: los paquetes de tama\xc3\xb1o fijo pueden contener \xc3\xa1tomos, mientras que no pueden contener strings largos._NEWLINE_Precisamente, los \xc3\xa1tomos son identificadores de strings almacenados en el servidor. Son similares a los identificadores de los recursos (Windows, Pixmaps, etc.) pero se diferencian de ellos de dos maneras. Primero, los identificadores de \xc3\xa1tomos son elegidos por el servidor, no por el cliente. En otras palabras, cuando un cliente solicita la creaci\xc3\xb3n de un nuevo \xc3\xa1tomo, \xc3\xa9ste solamente env\xc3\xada el servidor el string a ser almacenado, no su identificador; este identificador es elegido por el servidor y devuelto como contestaci\xc3\xb3n al cliente. La segunda diferencia importante entre los recursos y los \xc3\xa1tomos es que los \xc3\xa1tomos no est\xc3\xa1n asociados a los clientes. Una vez que se han creado, un \xc3\xa1tomo sobrevive hasta que el servidor termine o se reset\xc3\xa9e (\xc3\xa9ste no es el comportamiento por defecto de los recursos)._NEWLINE_Los \xc3\xa1tomos son identificadores y son por lo tanto \xc3\xbanicos. Sin embargo, un \xc3\xa1tomo y un identificador de recurso pueden coincidir. El string asociado con un \xc3\xa1tomo es llamado el nombre del \xc3\xa1tomo. El nombre de un \xc3\xa1tomo no puede ser cambiado despu\xc3\xa9s de la creaci\xc3\xb3n, y ninguno de dos \xc3\xa1tomos pueden tener el mismo nombre. Como resultado, el nombre de un \xc3\xa1tomo es com\xc3\xbanmente usado para indicar al \xc3\xa1tomo: "El \xc3\xa1tomo ABCD" significa, m\xc3\xa1s precisamente, "el \xc3\xa1tomo cuyo string asociado es ABCD", o "el \xc3\xa1tomo cuyo nombre es ABC". Un cliente puede solicitar la creaci\xc3\xb3n de un nuevo \xc3\xa1tomo y puede solicitar para el \xc3\xa1tomo (el identificador) de un string dado. Algunos \xc3\xa1tomos est\xc3\xa1n predefinidos (creado por el servidor con un identificador y string dados)._NEWLINE_Los \xc3\xa1tomos son usados para un n\xc3\xbamero de prop\xc3\xb3sitos, sobre todo relacionados con la comunicaci\xc3\xb3n entre diversos clientes conectados con el mismo servidor. En particular, son usados en asociaci\xc3\xb3n con las propiedades de las ventanas, que son descritas m\xc3\xa1s abajo._NEWLINE_La lista de todos los \xc3\xa1tomos que residiendo en un servidor puede ser impresa usando el programa xlsatoms. En particular, este programa imprime cada \xc3\xa1tomo (el identificador, es decir, un n\xc3\xbamero) con su nombre (su string asociado).\n_START_SECTION_\nPropiedades\n_START_PARAGRAPH_\nCada ventana tiene un conjunto predefinido de atributos y un conjunto de propiedades, todos almacenados en el servidor y accesible a los clientes por medio solicitudes apropiadas. Los atributos son datos acerca de una ventana, como su tama\xc3\xb1o, posici\xc3\xb3n, color de fondo, etc. Las propiedades son piezas arbitrarias de datos atados a una ventana. Al contrario de los atributos, las propiedades no tiene ning\xc3\xban significado a nivel del protocolo base de X Window. Un cliente puede almacenar datos arbitrarios en una propiedad de una ventana. Las propiedades son usadas sobre todo para la comunicaci\xc3\xb3n cliente a cliente._NEWLINE_Una propiedad es caracterizada por un nombre, un tipo, y un valor. Las propiedades son similares a las variables en lenguajes de programaci\xc3\xb3n imperativos, en que un cliente puede crear una nueva propiedad con un nombre y un tipo dados y almacenar un valor en \xc3\xa9l. Las propiedades est\xc3\xa1n asociadas a las ventanas: dos propiedades con el mismo nombre pueden existir en dos diferentes ventanas mientras tengan diferentes tipos y valores._NEWLINE_El nombre, el tipo, y el valor de una propiedad son strings; m\xc3\xa1s precisamente, son \xc3\xa1tomos, es decir, string almacenadas en el servidor y accesibles a los clientes v\xc3\xada identificadores. Una aplicaci\xc3\xb3n de cliente puede acceder a una propiedad dada usando el identificador del \xc3\xa1tomo que contiene el nombre de la propiedad._NEWLINE_Las propiedades son usadas sobre todo para la comunicaci\xc3\xb3n inter-cliente. Por ejemplo, la propiedad llamada WM_NAME (la propiedad nombrada por el \xc3\xa1tomo cuya secuencia asociada es \xe2\x80\x9cWM_NAME\xe2\x80\x9d) es usada para almacenar el nombre de las ventanas. Los manejadores de ventana t\xc3\xadpicamente leen esta propiedad para exhibir el nombre de las ventanas en su barra de t\xc3\xadtulo._NEWLINE_Algunos tipos de comunicaci\xc3\xb3n inter-cliente usan las propiedades de la ventana ra\xc3\xadz. Por ejemplo, seg\xc3\xban la especificaci\xc3\xb3n del manejador de ventana de freedesktop.org,\xe2\x80\x8b los manejadores de ventana deben almacenar el identificador de la ventana actualmente activa en la propiedad nombrada _NET_ACTIVE_WINDOW de la ventana ra\xc3\xadz. Los X resources, que contienen par\xc3\xa1metros de programas, tambi\xc3\xa9n son almacenados en las propiedades de la ventana ra\xc3\xadz; de esta manera, todos los clientes puede tener acceso, incluso si corren en diferentes computadores._NEWLINE_El programa xprop imprime las propiedades de una ventana dada; xprop -root imprime el nombre, el tipo, y el valor de cada propiedad de la ventana ra\xc3\xadz.'