Microventanas

El tema de este artículo puede no cumplir con las pautas generales de notabilidad de Wikipedia . Por favor, ayude a demostrar la notabilidad del tema citando fuentes secundarias confiables que sean independientes del tema y proporcionen una cobertura significativa del mismo más allá de una mera mención trivial. Si no se puede demostrar la notabilidad, es probable que el artículo sea fusionado , redirigido o eliminado . Buscar fuentes:  «Microwindows» – noticias  · periódicos  · libros  · académico  · JSTOR ( octubre de 2018 ) ( Aprenda cómo y cuándo eliminar este mensaje )

Este artículo se basa excesivamente en referencias a fuentes primarias . Por favor, mejore este artículo añadiendo fuentes secundarias o terciarias . Buscar fuentes:  «Microwindows» – noticias  · periódicos  · libros  · académico  · JSTOR ( octubre de 2018 ) ( Aprenda cómo y cuándo eliminar este mensaje )

En informática , Nano-X es un sistema de ventanas con todas las funciones necesarias para ser utilizado en un PC , un sistema integrado ^{[1] [2]} o una PDA . ^{[3] [4]} Es un proyecto de código abierto cuyo objetivo es llevar las características de los entornos de ventanas gráficas modernas a dispositivos y plataformas más pequeños. El proyecto cambió su nombre de Microwindows debido a las amenazas legales de Microsoft con respecto a la marca registrada Windows .

El sistema de ventanas Nano-X es extremadamente portátil y está escrito completamente en C. Se ha adaptado a las CPU de 16, 32 y 64 bits de Intel, al Broadcom BCM2837 ARM Cortex-A53 , así como a los chips MIPS R4000 (NEC Vr41xx) StrongARM y PowerPC que se encuentran en las PC de bolsillo y portátiles.

El sistema Nano-X Window se ejecuta actualmente en sistemas Linux con soporte de framebuffer de kernel , o utilizando un controlador X11 que permite ejecutar aplicaciones Microwindows sobre el escritorio X Window . Este controlador emula todos los modos de color verdadero y paleta de Microwindows para que se pueda obtener una vista previa de una aplicación utilizando las características de visualización del sistema de destino directamente en la pantalla del escritorio, independientemente de las características de visualización del escritorio. Además, se ha portado a Windows , Emscripten , Android (basado en la biblioteca Allegro ) y MS-DOS . Los controladores de pantalla Microwindows se han escrito basándose en las bibliotecas SDL1 y SDL2 más las bibliotecas Allegro y SVGAlib . También hay un controlador VESA y un controlador VGA de 16 colores y 4 planos.

Microwindows es esencialmente un diseño en capas que permite utilizar o reescribir diferentes capas para adaptarse a las necesidades de la implementación. ^[5] En el nivel más bajo, los controladores de pantalla , mouse / touchpad y teclado brindan acceso a la pantalla real y otro hardware de entrada del usuario. En el nivel medio, se implementa un motor de gráficos portátil, que brinda soporte para dibujos de líneas, rellenos de áreas, polígonos, recortes y modelos de color. En el nivel superior, se implementan tres API que brindan acceso al programador de aplicaciones gráficas. Actualmente, Microwindows admite las API Xlib, Nano-X y Windows Win32 / WinCE GDI . Estas API brindan una compatibilidad cercana con los sistemas Win32 y X Window , sin embargo, con una funcionalidad reducida. Estas API permiten que los programas se puedan portar desde otros sistemas fácilmente.

Las interfaces de los controladores de dispositivos se definen en device.h. Una determinada implementación de Microwindows vinculará al menos un controlador de pantalla, mouse y teclado al sistema. Las rutinas de nivel medio en el núcleo del motor gráfico independiente del dispositivo luego llaman al controlador de dispositivo directamente para realizar las operaciones específicas del hardware. Esta configuración permite que se agreguen diversos dispositivos de hardware al sistema Microwindows sin afectar la forma en que funciona todo el sistema.

Microwindows actualmente admite tres interfaces de programación de aplicaciones (API) diferentes. Este conjunto de rutinas maneja la actividad cliente - servidor , las actividades del administrador de ventanas como dibujar barras de título, cerrar cuadros, etc., así como también las solicitudes de salida gráfica del programador. Estas API se ejecutan sobre las rutinas del motor gráfico principal y los controladores de dispositivos.

La API NX11 es compatible con la API X Window . Se basa en la API Nano-X y proporciona funciones Xlib utilizando las funciones disponibles en la API Nano-X. Se puede compilar como una biblioteca independiente o junto con la biblioteca Nano-X como una biblioteca única llamada libPX11. En total, proporciona 180 funciones Xlib y stubs para funciones adicionales no implementadas.

Basándose en la API NX11, la biblioteca de interfaz gráfica de usuario FLTK se puede utilizar para proporcionar una GUI para programas de aplicación. La distribución Nanolinux utiliza la API NX11 y FLTK para implementar un sistema operativo Linux utilizando 19 MB de espacio en disco.

La API Nano-X está basada en el servidor mini-x escrito inicialmente por David Bell, que era una reimplementación de X en el sistema operativo MINIX . Sigue vagamente la API Xlib del sistema X Window, pero los nombres son GrXXX() en lugar de X...(). El modelo básico de cualquier API sobre Microwindows es inicializar los controladores de pantalla, teclado y mouse, y luego colgarse en un bucle select() esperando un evento. Cuando ocurre un evento, si es un evento del sistema como la actividad del teclado o mouse, entonces esta información se pasa al programa del usuario convertido en un evento de exposición, mensaje de pintura, etc. Si es un usuario que solicita una operación gráfica, entonces los parámetros se decodifican y se pasan a la rutina del motor GdXXX apropiada. Tenga en cuenta que el concepto de una ventana frente a las operaciones gráficas sin procesar se maneja en 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 en "coordenadas de pantalla" y se pasan a las rutinas del motor GdXXX central para hacer el trabajo real. Este nivel también define gráficos o contextos de visualización y pasa esa información, incluida la información de recorte, a las rutinas del motor principal.

La API que intenta cumplir con el estándar Microsoft Win32 y WinCE GDI es la API Microwindows. ^[6] Actualmente, hay soporte para la mayoría de las rutinas de dibujo y recorte de gráficos, así como para el dibujo automático de la barra de título de la ventana y el arrastre de ventanas para su movimiento. La API Microwindows está basada en mensajes y permite escribir programas sin tener en cuenta las políticas de administración de ventanas implementadas por el sistema. La API Microwindows actualmente 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, conocidos como wParam y lParam. Los mensajes se almacenan en la cola de mensajes de una aplicación y se recuperan mediante la función GetMessage. La aplicación se bloquea mientras espera un mensaje. Hay mensajes que corresponden a eventos de hardware, como WM_CHAR para la entrada del 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. Después de recuperar el mensaje, la aplicación envía el mensaje al procedimiento de manejo de la ventana asociada mediante DispatchMessage. Cuando se crea una clase de ventana, se especifica su procedimiento de manejo de mensajes asociado, de modo que el sistema sepa dónde enviar el mensaje.

La arquitectura de paso de mensajes permite que la API principal administre muchas funciones del sistema mediante el envío de mensajes sobre todo tipo de eventos, como la creación de ventanas, la necesidad de pintar, el movimiento, etc. De manera predeterminada, la función de manejo de ventanas asociada obtiene un "primer paso" en el mensaje y luego llama a la función DefWindowProc, que maneja las acciones predeterminadas para todos los mensajes. De esta manera, todas las ventanas pueden comportarse de la misma manera cuando se arrastran, etc., a menos que el usuario las anule específicamente. Las principales políticas de administración de ventanas se pueden redefinir simplemente reimplementando DefWindowProc, en lugar de realizar cambios en todo el sistema.

La unidad básica de organización de pantallas en Microwindows API es la ventana. Las ventanas describen un área de la pantalla en la que se puede dibujar, así como un "procedimiento de ventana" asociado para manejar los mensajes destinados a esta ventana. Los programadores de aplicaciones pueden crear ventanas a partir de clases predefinidas, como botones, cuadros de edición y similares, o definir sus propias clases de ventana. En ambos casos, el método de creación y comunicación con las ventanas sigue siendo exactamente el mismo.

El origen de Nano-X está en NanoGUI. NanoGUI fue creado por Alex Holden tomando el servidor mini-X de David Bell y las modificaciones de Alan Cox y agregando redes cliente/servidor. Luego, Gregory Haerr se interesó en el proyecto NanoGUI y comenzó a realizar amplias mejoras y modificaciones a NanoGUI. Alrededor de la versión 0.5, Gregory Haerr agregó soporte para múltiples API y comenzó a distribuir Microwindows. En Microwindows 0.84, se incorporaron todos los cambios anteriores de NanoGUI y desde entonces ha sido la distribución combinada NanoGUI/Microwindows. En enero de 2005, el sistema cambió su nombre a Nano-X Window System. Debido a que Nano-X solo sigue vagamente la API Xlib de X Window System, se desarrolló una interfaz adicional llamada NXlib, que proporciona una API compatible con Xlib basada en Nano-X.

• Microwindows en GitHub para la última versión
• Sitio web Microwindows.org
• Introducción a la programación en microventanas
• Introducción a la programación en microventanas, parte 2
• Introducción a la programación en microventanas, parte 3