200px|derecha|miniatura|Logo del Protocolo X del Sistema core de Windows. El Protocolo base del sistema X WindowRobert W. Scheifler and James Gettys: Sistema de Windows X: Core y extensiones de protocolos, Versión X 11, Disponibles de la 6 a la 11.6, Digital Press 1996, ISBN 1-55558-148-XRFC 1013Grant Edwards. Una introducción a X11 usando interfaces es la base del protocolo de X Window System, un sistema de ventanas de red que muestra bitmaps y que permite construir interfaces gráficas de usuarios en Unix, Unix-like y otros sistemas operativos. El sistema de ventanas X Window está 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ón; todos los programas de la aplicación actúan como un solo cliente, interactuando con el usuario. Esta interacción es regulada por el protocolo del base del sistema de ventanas X Window.Información sobre protocolos de Windows. Protocolos de Windows Existen otros protocolos relacionados con el sistema X Window, algunos utilizados en las capas superiores del protocolo X Window y otros como protocolos independientes.
En el protocolo base de X Window System, solo cuatro clases de paquetes son enviadas, asíncronamente, sobre la red: peticiones, respuestas, los acontecimientos, y los errores. Las “peticiones” son enviadas por un cliente al server para preguntar si puede mejorar alguna aplicación (por ejemplo crear una nueva ventana) y además son devueltos a la persona que los envió para que reciba los datos (Repuestas). Las “respuestas” son enviadas por un cliente para confirmar algún dato. Los “eventos” son enviados por un usuario para notificar a otros de que hay alguna junta de interés o trabajo. Los “errores” 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ífica para que el usuario no mande la petición por otra red. Algunas extensiones al protocolo core existente, cada una con sus propias peticiones, respuestas, eventos y errores.
X se originó en el Instituto Tecnológico de Massachusetts en 1984 (su liberación X11 actual apareció en septiembre de 1987). Fue diseñado por Bob Scheifer y Jim Gettys, pusieron como principio primordial del proyecto “Crearemos un mecanismo, no una política”. Como resultado, el protocolo core no específica la interacción entre clientes y entre un cliente y el usuario. Estas interacciones están sujetas por especificaciones separadas,Jim Gettys. Abriendo un Desktop hacia la tecnología como el ICCCM y la freedesktop.org especificaciones. Son típicamente automáticos, hasta usando un dado Widget toolkit.
Descripción general
miniatura|200px|derecha|Un ejemplo de interacción entre un cliente y un servidor.
La comunicación entre el servidor y los clientes se hace mediante el intercambio de paquetes sobre un canal. La conexión se establece por el cliente (la forma en que el cliente se inicia no se ha especificado en el protocolo). El cliente también envía el primer paquete, que contiene el orden del byte a ser utilizado y la información sobre la versión del protocolo y el tipo de autenticación que el cliente espera que el servidor usará. La respuesta del servidor mediante el envío de un paquete de vuelta indica la aceptación o el rechazo de la conexión, o con una solicitud de una autenticación adicional. Si la conexión es aceptada, el paquete de aceptación contiene los datos que el cliente debe usar en la interacción posterior con el servidor.
Después de que se establezca la conexión, cuatro tipos de paquetes son intercambiados entre el cliente y el servidor sobre el canal de comunicación:
Petición: El cliente pide información al servidor o solicita que éste realice una acción. Respuesta: El servidor responde a una petición. No todas las peticiones generan respuestas. Evento: El servidor informa al cliente de un acontecimiento, tal como la entrada del teclado o del ratón, que una ventana está siendo movida, redimensionada, expuesta, etc. Error: El servidor envía un paquete de error si una petición es inválida. Puesto que las respuestas están en cola, los paquetes de error generados por una petición pueden no enviarse inmediatamente.
Los paquetes de la petición y de la respuesta tienen una longitud diversa, mientras que los paquetes de eventos y de error tienen una longitud fija de 32 bytes.
Los paquetes de petición son numerados secuencialmente por el servidor tan pronto como los recibe: la primera petición de un cliente se numera 1, la segunda 2, etc. Los 16 bits menos significativos del número secuencial de una petición se incluyen en los paquetes de la respuesta y del error, si los hay, generados por la petición. También son incluidos en los paquetes de eventos, para indicar el número secuencial de la petición que el servidor está actualmente procesando o acaba de terminar de procesar.
Ventanas
Una posible colocación de algunas ventanas: 1 es la ventana raíz, que cubre la pantalla entera; 2 y 3 son ventanas de nivel superior; 4 y 5 son subventanas de 2. Las partes de una ventana que están fuera de su padre no son visibles.
Lo que es usualmente llamado «ventana» en la mayoría de las interfaces gráficas de usuarios, en el X Window System se llama «ventana de nivel superior». El término ventana también es usado para denotar las ventanas que descansan dentro de otra ventana, es decir, subventanas de una ventana padre. Los elementos gráficos tales como los botones, menús, iconos, etc. pueden ser creados usando subventanas.
Un cliente puede solicitar la creación de una ventana. Más precisamente, puede solicitar la creación de una subventana para una ventana existente. Como resultado, las ventanas creadas por los clientes se arreglan en forma de 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 en el arranque. Todas las otras 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 la pantalla, y descansa detrás del resto de las ventanas. Sin embargo la ventana raíz puede ser más grande que la pantalla, en este caso el usuario puede desplazarse alrededor del área visible.
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á 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ón 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.
Cada ventana tiene un conjunto asociado de atributos, tales como la geometría de la ventana (tamaño y posición), 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.
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.
izquierda|miniatura|350px|Anatomía de una ventana FVWM. El área blanca es la ventana como ha sido creada y vista por la aplicación cliente.
El marco decorativo y la barra de título (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én maneja la entrada relacionada con estos elementos, tales como redimensionar la ventana cuando el usuario hace clic 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íz. Desde el punto de vista del protocolo base, el manejador de ventanas es un cliente, no diferente de otras aplicaciones.
Los datos acerca de una ventana pueden ser obtenidos corriendo el programa xwininfo. Pasándole el argumento de línea de comando -tree, este programa muestra el árbol de subventanas de una ventana, junto con sus identificadores y datos de geometría.
Pixmaps y drawables
Un pixmap es una región de memoria que puede ser usada para dibujo (drawing) de contenido. A diferencia de las ventanas, los pixmaps no se muestran automáticamente en la pantalla. Sin embargo, el contenido de un pixmap (o una parte de él) puede ser transferido a una ventana y viceversa. Esto permite técnicas tales como double buffering. La mayoría de las operaciones gráficas que se pueden hacer en ventanas, también se pueden hacer en pixmaps.
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.
Los contextos gráficos y las fuentes
El cliente puede pedir un número de operaciones gráficas, tales como limpiar un área, copiar un área en otra, dibujar puntos, líneas, rectángulos, 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.
La mayoría de los pedidos 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 del primero plano, el color del fondo, la fuente del texto, y otros parámetros gráficos. Cuando se pide una operación gráfica, el cliente incluye un contexto gráfico. No todos los parámetros del contexto gráfico afectan a la operación: por ejemplo, la fuente no tiene efecto al dibujar una línea.
El protocolo base específica el uso de las fuentes del lado del servidor.comp.fonts FAQ: X11 Info Tales fuentes son almacenadas como archivos, y el servidor tiene acceso directamente vía el sistema de archivos local o vía 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á) o descargarla del servidor (si no es usada por otros clientes). Un cliente puede pedir la información de carácter general sobre una fuente (por ejemplo, la "subida" (ascent) de la fuente) y el espacio que una específica secuencia de caracteres (string) toma cuando es dibujada con una fuente determinada.
miniatura|450px|El programa xfontsel permite al usuario ver los glyphs de una fuente.
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 especifican cómo las fuentes deben ser nombradas de acuerdo a sus atributos. Estas convenciones también especifican los valores de las propiedades opcionales que pueden estar adjuntas a las fuentes.