Microventanas

La API NX11 cumple con la API de X Window . Se basa en la API Nano-X y proporciona funciones Xlib utilizando las funciones disponibles en la API Nano-X. Puede compilarse como una biblioteca independiente o junto con la biblioteca Nano-X como una única biblioteca llamada libPX11. En total, proporciona 180 funciones Xlib y funciones auxiliares para otras funciones no implementadas.

Basándose en la API NX11, la biblioteca de interfaz gráfica de usuario FLTK permite crear una interfaz gráfica para programas de aplicación. La distribución Nanolinux utiliza la API NX11 y FLTK para implementar un sistema operativo Linux que requiere 19 MB de espacio en disco.

La API Nano-X se basa en el servidor mini-x, escrito inicialmente por David Bell, que era una reimplementación de X en el sistema operativo MINIX . Sigue de forma general la API Xlib del sistema X Window, pero con nombres que comienzan con GrXXX() en lugar de X...(). El modelo básico de cualquier API sobre Microwindows consiste en inicializar los controladores de pantalla, teclado y ratón, y luego esperar un evento en un bucle select(). Cuando se produce un evento, si es un evento del sistema, como la actividad del teclado o el ratón, esta información se pasa al programa de usuario convertida en un evento de exposición, un mensaje de dibujo, etc. Si se trata de una solicitud de operación gráfica por parte del usuario, los parámetros se decodifican y se pasan a la rutina del motor GdXXX correspondiente. Cabe destacar que el concepto de ventana frente a operaciones gráficas puras se gestiona a este nivel de API. Es decir, la API define los conceptos de qué es una ventana, cuáles son los sistemas de coordenadas, etc., y luego las coordenadas se convierten a "coordenadas de pantalla" y se pasan a las rutinas principales del motor GdXXX para que realicen el trabajo real. Este nivel también define los contextos gráficos o de visualización y transmite esa información, incluida la información de recorte, a las rutinas principales del motor.

La API que intenta cumplir con el estándar GDI de Microsoft Win32 y WinCE es la API de Microwindows. ^{[ 6 ]} Actualmente, admite la mayoría de las rutinas de dibujo y recorte de gráficos, así como el dibujo automático de la barra de título de la ventana y el arrastre de ventanas para su movimiento. La API de Microwindows se basa en mensajes y permite escribir programas sin tener en cuenta las políticas de administración de ventanas que implemente el sistema. Actualmente, la API de Microwindows no es cliente/servidor.

El mecanismo de comunicación fundamental en la API de Microwindows es el mensaje. Un mensaje consta de un número de mensaje conocido y dos parámetros, denominados wParam y lParam. Los mensajes se almacenan en la cola de mensajes de la aplicación y se recuperan mediante la función GetMessage. La aplicación se bloquea mientras espera un mensaje. Existen mensajes que corresponden a eventos de hardware, como WM_CHAR para la entrada de teclado o WM_LBUTTONDOWN para la pulsación del botón del ratón. Además, se envían eventos que señalan la creación y destrucción de ventanas: WM_CREATE y WM_DESTROY. En la mayoría de los casos, un mensaje se asocia a una ventana, identificada como HWND. Tras recuperar el mensaje, la aplicación lo envía al procedimiento de gestión de la ventana asociada mediante DispatchMessage. Al crear una clase de ventana, se especifica su procedimiento de gestión de mensajes asociado, de modo que el sistema sabe dónde enviar el mensaje.

La arquitectura de paso de mensajes permite que la API principal gestione numerosas funciones del sistema mediante el envío de mensajes ante diversos eventos, como la creación de ventanas, la necesidad de pintar, el movimiento, etc. Por defecto, la función de gestión de ventanas asociada recibe un primer análisis del mensaje y, a continuación, llama a la función DefWindowProc, que gestiona las acciones predeterminadas para todos los mensajes. De este modo, todas las ventanas pueden comportarse de la misma manera al arrastrarlas, etc., a menos que el usuario especifique lo contrario. Las principales políticas de gestión de ventanas pueden redefinirse simplemente reimplementando DefWindowProc, en lugar de realizar cambios en todo el sistema.

La unidad básica de organización de pantalla en la API de Microwindows es la ventana. Las ventanas describen un área de la pantalla donde se dibuja, así como un procedimiento asociado para gestionar los mensajes destinados a dicha ventana. Los programadores de aplicaciones pueden crear ventanas a partir de clases predefinidas, como botones, cuadros de edición, etc., o definir sus propias clases de ventana. En ambos casos, el método para crear y comunicarse con las ventanas sigue siendo el mismo.