UNIVERSIDAD AUTONOMA METROPOLITANA148.206.53.84/tesiuami/UAM3344.pdf · mrroauccron Introducción X...

UNIVERSIDAD AUTONOMA METROPOLITANA

Unidad Iztapalapa Proyecto Terminal

División: CBI

Carrera: Licenciatura en Computación

Asesor: Ing. Jorge Lozano Moreno

Proyecto: Construcción de interfaces gráficas sobre plataforma UNIX y X Window

Constancia de finalización de Proyecto Terminal

Por medio de este conducto hago de su conocimiento que Eduardo Flores Cardoso, alumno de la Lic. en Computación en la Universidad Autónoma Metropolitana, finalizó bajo mi asesoría su Proyecto Terminal, requisito indispensable para la titulación, el cual consistió en lo siguiente:

Se diseñó una Herramienta CASE sobre plataforma UNIX y X Window System que permite diseñar el “front end” para una aplicación. Una vez efectuado el diseño, la herramienta es capaz de generar su código en lenguaje C. Esta herramienta CASE fue desarrollada sobre el administrador de ventanas OSFMotif, para el sistema operativo Solaris 2.3 en una estación de trabajo Sun SPARCStation 2.

La finalidad de la herramienta es brindar a los programadores un CASE que facilite la creación de sistemas bajo X1 1. El programador, dentro de una área de diseño, se encargará únicamente de colocar las ventanas, botones, mentís, cuadros de texto, cuadros de dialogo, etc. a través de la barra de herramientas que proporciona el CASE y finalmente seleccionará la generación de código, con lo cual creará un archivo que contendrá el código fuente en C del “front end”, listo para ser modificado al gusto del programador, o para enlazarlo a órdenes de manejo de bases de datos, comunicaciones, etc.

Considero de gran utilidad a esta herramienta, pues el programador deja de preocuparse del diseño de widgets dentro del desarrollo de sistemas, además de que la experiencia de desarrollo de este tipo de herramientas en México es casi inexistente, aun cuando en otros países es un recurso habitual para todo programador y desarrollador de sistemas.

El presente trabajo proporciona una herramienta con la cual los programadores podrán llagar a utilizar el sistema X Window bajo plataformas UNIX para desarrollar interfases gráficas de usuario. Se introduce con detalle la programación X Window, las herramientas Xt Intrinsics y la herramienta en propiedad OSFMotif. Además, se proporciona los componentes y caractensticas necesarios acerca del sistema operativo UNIX con la finalidad de apoyar al desarrollador en la construcción de interfases gráficas.

Sin más por el momento, me despido de usted, esperando le sea útil el presente trabajo.

Atentamente

Profesor Asociado D

mrroauccron

Introducción

X Window crea ventanas. Se trata de la herramienta de software para el desarrollo de interfases gráficas de usuario (GUIs) sobre estaciones de trabajo. X Window es para los sistemas UNIX lo que es Windows para los sistemas MS-DOS, pero con una diferencia importante: los sistemas X Window son un estándar aceptado por la industria para los sistemas de ventanas en UNIX. Esta estandarización tiene consecuencias de gran alcance: las interfases gráficas de usuario desarrolladas para una computadora se pueden ejecutar en computadoras completamente diferentes. Los sistemas X Window proporcionan una salida común para estaciones de trabajo, grandes computadoras, minicomputadoras y microcomputadoras conectadas en red.

La bajada continua en los precios de las microcomputadoras ha colocado a los sistemas X Window al alcance de literalmente millones de usuarios de computadoras. Todos los programas que aparecen en este trabajo se han desarrollado y probado en una estación de trabajo Sun SPARCStation. El sistema operativo usado, basado en el UNIX System V, y desarrollado por el líder de la industria UNIX sobre computadoras personales, fue el SCO Open Desktop personal System, con el sistema de desarrollo Open Desktop Development System. El software de desarrollo incluye X Window, con la herramienta OSFMotif y el lenguaje de programación C. El uso de sistemas de desarrollo alternativos como el recientemente lanzado entorno multitarea DESQviewiX de Quarterdeck Office System puede reducir los requisitos de hardware. Las aplicaciones X Window se pueden ejecutar en PC con procesadores 486 y superiores.

Este trabajo está dividido en dos secciones. En la primera sección, compuesta por cinco capítulos, se introduce con detalle la programación X Window, las herramientas Xt Intrinsics y la herramienta en propiedad OSFiMotif. Se incluyen varios programas que son detalladamente analizados.

La segunda sección incluye 11 capítulos que están dedicados al Sistema Operativo. El sistema UNIX ha aumentado significativamente en funcionalidad desde su implementación en los Laboratorios Bell, en los primeros años setentas. No obstante, las fknciones básicas del sistema y su estructura permanecen sin cambios. En estos capítulos se ofrece una descripción de fácil lectura de las funciones básicas del sistema con la finalidad de apoyar al desarrollador de inerfases gráficas.

i

"l̂ l"l "-."......._."l I -.__ ".l_l_

Contenido

Contenido

Capítulo I . Introducción al Sistema

El Sistema X Window .................................................................................................... Historia y necesidad ............................................................................................. Dispositivos físicos (Hardware) ........................................................................... Arquitectura Cliente/Servidor .............................................................................. Software ...............................................................................................................

Otros sistemas de ventanas ............................................................................................. Historia y objetivos .............................................................................................. Implementaciones ................................................................................................

Puntos clave .................................................................................................................... ¿ En qué consiste el sistema X Window ? ........................................................... El sistema X Window .......................................................................................... Hardware ............................................................................................................. Arquitectura Cliente/Servidor ............................................................................. Conexiones .......................................................................................................... Software .............................................................................................................. Interfases gráficas de usuario ..............................................................................

Analogías y diferencias ........................................................................................

1 2 3 5 7 10 11 11 13 14 14 14 14 14 15 15 15

Capítulo 2 . El programa “Hola Mundo ’’ Funciones X Window ..................................................................................................... 17 Examen del programa “Hola Mundo” ............................................................................ 18

Inclusión de los archivos de cabecera .................................................................. 18 Declaraciones ....................................................................................................... 18 Establecimiento de la conexión ........................................................................... 19 Creación de una ventana ...................................................................................... 20 Notificación a las demás aplicaciones ................................................................. 20 Creación de un contexto gráfico .......................................................................... 21 Selección del tipo de suceso de entrada a procesar ............................................. 21 Visualización de ventanas ................................................................................... 21 Ejecución del bucle principal .............................................................................. 21 Terminación del programa .................................................................................. 23

Modificaciones posibles ................................................................................................ 23 Código fuente del programa “Hola Mundo” ................................................................. 24 Puntos clave ................................................................................................................... 27

El primer programa ............................................................................................. 27 Funciones de un programa X Window ................................................................ 27 Modificaciones posibles ...................................................................................... 27

I

Contenido

Capítulo 3 . Conceptos básicos y terminología

El protocolo X ................................................................................................................ 29 Peticiones y formato de petición .......................................................................... 30 Respuestas y formato de respuestas ..................................................................... 31 Errores y formato de errores ................................................................................. 31 Formato de suceso ................................................................................................ 32

Archivos de cabecera ...................................................................................................... 33 Archivos de cabecera estándar ............................................................................. 33

Nomenclatura Xlib y convenios para los argumentos .................................................... 34 Recursos ......................................................................................................................... 35

Ventanas ............................................................................................................... 35 Contextos gráficos ............................................................................................... 36 Tipos de letra (Fonts) ........................................................................................... 37 Cursores ............................................................................................................... 37 Mapas de colores (Colormaps) ............................................................................ 38 Mapas de puntos (pixmap) ................................................................................... 38

Sucesos ........................................................................................................................... 38 Tipos de sucesos ................................................................................................... 39 Estructura de sucesos ........................................................................................... 45 Máscaras de sucesos ............................................................................................ 46

Puntos clave ................................................................................................................... 48 Protocolo X .......................................................................................................... 48 Peticiones ............................................................................................................. 48 Respuestas ............................................................................................................ 48 Errores .................................................................................................................. 48 Formato de sucesos .............................................................................................. 48 Archivos de cabecera estándar ............................................................................. 48 Nmenclatura Xlib Y convenios para los argumentos ......................................... 49 Recursos ............................................................................................................... 49 Ventanas ............................................................................................................... 49 Contextos gráficos ................................................................................................ 49 Tipos de letra ........................................................................................................ 49 Cursores ............................................................................................................... 49

Mapas de puntos ................................................................................................... 50 Sucesos ................................................................................................................. 50 Tipos de Sucesos .................................................................................................. 50

Mapas de colores .................................................................................................. 49

Capítulo 4 . Ventanas y técnicas de trabajo con ventanas

Conceptos básicos .......................................................................................................... 51 Analogía del escritorio ......................................................................................... 52 Terminología básica ............................................................................................ 53

Geometría de las ventanas ................................................................................... 59 características de las ventanas ....................................................................................... 59

Características propias de las ventanas ................................................................ 60 Atributos de las ventanas ..................................................................................... 61

Ciclo de vida de las ventanas ......................................................................................... 64

I1

.- .. " " ".-." .......................... ," .

Contenido

Creación de ventanas ............................................................................................ 64 Visualización de ventanas ..................................................................................... 68 Destrucción de ventanas ....................................................................................... 70

Funciones de configuración de ventanas ........................................................................ 70 Desplazamiento y redimensionamiento de ventanas ............................................ 70 Establecimiento de la anchura del borde de la ventanas ....................................... 71 Modificación del orden de apilamiento de las ventanas ....................................... 72

Modificación de los atributos y configuración de la ventana ......................................... 73 La función XChangeWindowAttributes ............................................................... 73 Modificación de los atributos individuales de las ventanas .................................. 74 La función XConfigureWindow ........................................................................... 75

Cambios de estado de la ventana y sucesos Expose ....................................................... 76 El suceso CirculateNotify ..................................................................................... 76 El suceso ConfigureNotify ................................................................................... 77 El suceso CreateNotify ......................................................................................... 77 El suceso DestroyNotify ....................................................................................... 78 El suceso GravityNotify ........................................................................................ 78 El suceso MapNotify ............................................................................................ 78 El suceso MappingNotify ..................................................................................... 79 El suceso ReparentNotify ..................................................................................... 79 El suceso UnmapNotify ........................................................................................ 80 El suceso Visibility ............................................................................................... 80

Puntos clave .................................................................................................................... 81 Principios básicos ................................................................................................. 81 Terminología básica de las ventanas .................................................................... 81 Visibilidad de las ventanas ................................................................................... 81 Terminología sobre la geometría de las ventanas ................................................ 81 Características y atributos de las ventanas ........................................................... 81 Ciclo de vida de las ventanas ............................................................................... 82 Gestores de ventanas ............................................................................................ 82

Capítulo 5 . Herramientas. conceptos y técnicas Conceptos básicos ........................................................................................................................ 83

Arbol de widgets ............................................................................................................... 85 La clase de widgets de Intrinsics ...................................................................................... 86 La clase de widgets de la caja de herramientas ................................................................ 86 Interrelación entre clases de widgets ................................................................................ 87 Visión general de los recursos de widgets ....................................................................... 88

Estructura de una aplicación Motif ............................................................................................. 88 Ejemplo 1 : Revisión del programa Hola Mundo ......................................................................... 89

Paso 1: Revisión del programa Hola Mundo .................................................................... 89

Terminología básica .......................................................................................................... 84

Paso 2: Incluir un archivo de cabecera de Motif ............................................................... 89 Paso 3: Inicializar el programa y la caja de herramientas ................................................. 90 Paso 4: Creación y gestión de los widgets ........................................................................ 91 Paso 5: Registrar llamadas de retorno, acciones y gestores de sucesos ............................ 91 Paso 6: Activación de los widgets .................................................................................... 91 Paso 7: Bucle de sucesos .................................................................................................. 91

I11

" ... ...... ..̂.....I. .xII"-. .-_ .- il ..... "" -..-..-.."..."....I _ - ._

Contenido

Ejemplo 2: Revisión del programa Hola Mundo .......................................................................... 93 Paso 2: Incluir un archivo de cabecera público ................................................................. 93 Paso 3: Inicializar el programa y la caja de herramientas ................................................. 93 Paso 5: Registrar llamadas de retorno. acciones y gestores de sucesos ............................ 94

Inicialización por omisión ................................................................................................ 95 Inicialización de los elementos internos de la caja de herramientas ................................. 96 Manejo de la visualización ............................................................................................... 97 Creación del widget Shell (de interfaz) inicial .................................................................. 98 Salida de las aplicaciones .................................................................................................. 99

Ciclo de vida del widget .................................................................................................... 100 Los widgets Shell .............................................................................................................. 103

Inicialización de la caja de herramientas y funciones relacionadas ............................................. 95

Widgets ......................................................................................................................................... 99

Recursos ........................................................................................................................................ 103 Orden de especificaclon de recursos ................................................................................. 103 Convenios de nomenclatura de los recursos ...................................................................... 104 Caracteres comodines en la especificación de recursos .................................................... 104 Archivos de recursos ......................................................................................................... 106 Recursos del widget Core (núcleo) ................................................................................... 106 Recursos de los widgets Composite (compuestos) ........................................................... 108

Llamadas de retorno ..................................................................................................................... 109 Codificación de los procedimientos de llamadas de retorno ............................................. 109 Adición y eliminación de llamadas de retorno .................................................................. 109

Ejemplo 3: Un programa que utiliza el widget RowColumn ........................................................ 111 Ejemplo 4: Un programa que utiliza varios widgets ..................................................................... 113 Widgets dinámicos (popus) .......................................................................................................... 115 Ejemplo 5: Programa con menú de ayuda dinámico .................................................................... 116 Especificación de recursos de todos los ejemplos ........................................................................ 120 Puntos clave ................................................................................................................................. 122

El papel de la caja de herramientas .................................................................................. 122 Programadores de la caja de herramientas ....................................................................... 122 Arb01 de widgets ............................................................................................................... 122 Clases de widgets .............................................................................................................. 122 Las aplicaciones Motif ..................................................................................................... 122 Ciclo de vida de los widgets ............................................................................................. 122 Recursos ............................................................................................................................ 123 Llamadas de retorno ......................................................................................................... 123 Widgets dinámicos ........................................................................................................... 123

. .

Capítulo 6 . Introducción al sistema UNIX Diferentes versiones de Unix ........................................................................................................ 124 Conceptos elementales sobre sistemas operativos ........................................................................ 124 Sistemas de un solo usuario .......................................................................................................... 124

Sistemas de multiproceso ............................................................................................................. 125 Sistemas de varios usuarios .......................................................................................................... 125

Capítulo 7 . Principios básicos Sistema de almacenamiento .......................................................................................................... 126 Ordenes ......................................................................................................................................... 126 Archivos temporales ..................................................................................................................... 127 Bibliotecas .................................................................................................................................... 127

IV

Contenido

Usuarios ........................................................................................................................................ 128 Admmistración ............................................................................................................................. 128 Dispositivos .................................................................................................................................. 130 Otros directorios y archivos .......................................................................................................... 130

Capítulo 80 Encendido y apagado del sistema Encendido ...................................................................................................................................... 131 Apagado ......................................................................................................................................... 132

Capítulo 9 . Conexión desconexión de usuarios Conexión (logging-in) ................................................................................................................... 134 Desconexión (logging-out) ............................................................................................................ 135

Capítulo 10 . Shell Shell ............................................................................................................................................... 136

Capítulo 11 . Control de usuarios en el sistema Creación de un usuario .................................................................................................................. 137 Eliminación de un usuario ............................................................................................................. 137 Grupos ........................................................................................................................................... 138

Capítulo 12 . Dispositivos Agregar un dispositivo a Unix ....................................................................................................... 139 Dispositivos estructurados por bloques (sistemas de archivos) .................................................... 140 Dispositivos crudos y estructurados por bloques .......................................................................... 140 Dispositivos de caracteres ............................................................................................................. 140

Capítulo 13 . Sistemas de archivos y su mantenimiento Respaldo y recuperación de discos .............................................................................................. 142

La orden tar ........................................................................................................................ 143 La orden dd ........................................................................................................................ 143

Las órdenes dump y resto .................................................................................................. 142

Transferencia de archivos entre sistemas ...................................................................................... 143 Ocupación y uso del sistema de almacenamiento ......................................................................... 144

La orden du ....................................................................................................................... 144 La orden quot ..................................................................................................................... 144

El bit SUID (super user id) ................................................................................................ 144

La orden df ......................................................................................................................... 144 Bits especiales de acceso a los archivos ....................................................................................... 144

El bit SGID (super user group id) ...................................................................................... 145 El bit pegajoso (sticky bit) ................................................................................................. 145

Sistema de archivos ....................................................................................................................... 145 Estructura del disco ........................................................................................................... 145 Directorios ......................................................................................................................... 145 Nodos i ............................................................................................................................... 145

V

. . ""11"" .......... .- ... . ... II_ .̂....I

Contenido

Dispositivos de disco por bloques y crudos ....................................................................... 146 Banco de buffers ................................................................................................................ 146 Otras órdenes de mantenimiento del sistema de archivos ................................................. 146

Las órdenes mount y umount ........................................................................................................ 146

Capítulo 14 . Consideraciones de rendimiento Ordenes estándares ........................................................................................................................ 148

Orden iostat ........................................................................................................................ 148 Orden sa ............................................................................................................................. 148 Orden ac ............................................................................................................................. 149

Consideraciones generales del rendimiento del disco ................................................................... 149

Capítulo 15 . Seguridad en los sistemas Unljc Permisos sobre archivos ................................................................................................................ 150 Acceso a los dispositivos .............................................................................................................. 150 Otros puntos .................................................................................................................................. 151

Capítulo 16. Algunas órdenes importantes para los administradores Orden make ................................................................................................................................... 152 Sistema de control de código fuente ............................................................................................. 152 awk ............................................................................................................................................... 153 Programas para la bitácora de procesos ....................................................................................... 154

VI

1" - ............ ..--.p... .. ..... ............... _" - ..........

Introducción al Sistema X Window

Capítulo 1

Introducción al sistema X Window

Bienvenidos al sistema X Window (también llamado X Window y en otras ocasiones, aunque erróneamente X Windows). En los últimos años este sistema se ha convertido en un estándar para el desarrollo de inteq4ases grá$cas de usuario en estaciones de trabajo (graphics user interfaces on workstations). Una interfaz gráfica de usuario (GUI) se puede defmir brevemente como una interfaz computadoralusuario que se ejecuta en modo gráfico. Las estaciones de trabajo son computadoras de sobremesa con capacidades gráficas y de computación más potentes que las microcomputadoras de gama alta.

Debido a la independencia de dispositivo de X Window, las interfases gráficas de usuario desarrolladas sobre una computadora, se pueden ejecutar en distintas computadoras. Los sistemas X Window frecuentemente proporcionan una salida común para estaciones de trabajo, grandes sistemas (mainframes), minicomputadoras y microcomputadoras conectados en red. Antes de examinar atentamente los sistemas X Window, consideremos la necesidad de los sistemas de ventanas y de las interfases gráficas de usuario (GUls, abreviatura de Graphical User Interface).

Cada avance apreciable en el hardware de las computadoras ha significado un progreso significativo en la forma en la que los usuarios finales y los especialistas interactúan con las computadoras, redundando todo ello en una forma de trabajo más cómoda y productiva.

Algunas personas aún recuerdan los años de las tarjetas perforadas, años cincuenta, sesenta y principios de los setenta. En aquella época, la mayor parte de las personas no cualificadas se veían forzadas a elegir entre dos opciones poco satisfactorias: usar solamente unos pocos programas de computadora o depender de especialistas que les ayudasen a acceder a los datos que necesitaban. Los programadores se consideraban afortunados si podían probar un programa tres o cuatro veces al día. Las salidas estándar constaban de líneas variadas en las que tan sólo había números y letras, todas en mayúscula.

Gradualmente, los terminales de rayos catódicos (CRT) reemplazaron a las tarjetas perforadas y a las lectoras de tarjetas. Grupos cada vez mayores de usuarios utilizaban los terminales para visualizar la información contenida en las grandes computadoras centrales situadas en la habitación contigua o en cualquier punto del continente. Los programadores podían desarrollar programas y probarlos de forma interactiva, dialogando con la computadora. Las utilidades de salida avanzaron también. El poder visualizar los resultados no seguía significando el tener que ir hasta la impresora. La mayoría de los terminales ofrecían nuevas posibilidades como, por ejemplo, las letras minúsculas. Pero como decía Henry Ford, con un terminal CRT estándar se puede tener cualquier tipo de letra siempre y cuando sea de "Computadora". Incluso hoy en día, muchos de los terminales conectados a grandes computadoras no pueden generar gráficos.

Los efectos de la revolución de las microcomputadoras nos rodean. ¿Quién no ha visto deslumbrantes pantallas y llamativos folletos impresos con computadoras relativamente baratas? Los éxitos de esta revolución han creado nuevos problemas. Durante mucho tiempo los usuarios de las microcomputadoras compatibles IBM sufrieron la dificultad de la transferencia de archivos de un formato a otro. Los conocimientos adquiridos en el manejo de la función de impresión de las hojas de cálculo han sido, hasta muy recientemente virtualmente inútiles para imprimir un documento a través de un procesador de textos.


En realidad, cambiar de procesador de texto significaba tener que aprender de nuevo los modos de impresión.

Los diseñadores de software también han sufrido las consecuencias de los problemas de compatibilidad. El software gráfico es difícil de escribir y de depurar. Un programa que dibuje una línea en la pantalla debe manejar dos dispositivos separados pero relacionados: el controlador de video y el monitor. Un programa escrito para un estándar gráfico compatible IBM, no funcionará correctamente si se usan otros estándares gráficos en la misma computadora. Transformar programas gráficos para ejecutarlos en un Macintosh, una estación de trabajo o una gran computadora, genera más problemas que resultados.

Las microcomputadoras compatibles IBM más antiguas usan gráficos Hércules (monocromo) o CGA (color). En 1987, IBM introdujo la línea de computadoras Psi2 equipadas con gráficos VGA, que en gran medida han ido reemplazando a Hércules, CGA y a otro estándar gráfico de IBM llamado EGA. Desde principios de los noventa VGA se ha convertido en el estándar gráfico de base para los compatibles IBM.

La mayor resolución disponible con VGA es de 640 x 480, una pantalla se divide en 640 líneas horizontales de 480 puntos cada una, dando a un punto direccionable el nombre de pixel. Son comunes los sistemas gráficos capaces de manejar una resolución de 800 x 600 puntos, siendo conocidos frecuentemente como Super VGA, o VGA Extendida (Extended VGA) pero ni la nomenclatura ni las especificaciones técnicas son estándar. Existen dos estándares distintos para los sistemas gráficos de 1024 x 768 puntos, usados normalmente en el diseño asistido por computadora y en los sistemas de autoedición. Al escribir esto existe una barrera en el precio para una resolución superior a la de 1024 x 768. Los sistemas con mayor resolución son relativamente caros y no son estándar. Por otro lado, la resolución típica en una estación de trabajo es de 1152 x 900, siendo normales resoluciones mayores.

Los diseñadores de los programas gráficos tradicionales están siempre contando puntos (pixels), miles de puntos, y además deben estar familiarizados con códigos arbitrarios para los patrones y colores. Transportar una aplicación gráfica de una computadora a otra puede durar meses. Lo mismo que el sistema de video Beta perdió su participación en el mercado frente al sistema VHS tecnológicamente inferior, las microcomputadoras Rainbow de Digital Equipment Corporation y las Professional de Texas Instruments no pudieron competir con los compatibles IBM, en buena parte debido a los diferentes estándares gráficos. El sistema X Window se dirige hacia la resolución de estos problemas.

El sistema X Window El sistema X Window se ha convertido en un estándar de los sistemas de ventanas independiente del hardware y de los sistemas operativos. Es una utilidad para desarrollar sistemas gráficos de alta resolución tanto en monocromo como en color. En la Figura 1-1 se muestra un esquema de este sistema.

Historia y necesidad En 1984, el Laboratory for Computer Science del Instituto Tecnológico de Massachusetts (MIT) en Cambridge, Massachusetts, inició el proyecto Athena encabezado por Robert Scheifer y Jim Gettys. Como otras muchas organizaciones, tanto mercantiles como publicas, el MIT utiliza gran variedad de CPUs, terminales, y sistemas operativos. El proyecto Athena tenia una meta muy concreta, los programas deberían estar disponibles interactivamente para los usuarios sobre cualquier estación, en cualquier lugar del campus. El punto de partida fue el sistema de ventanas de la Universidad de Stanford denominado W.

Inicialmente el sistema X Window estuvo disponible para los diseñadores en el año 1986, con la versión 10.4. Los grandes fabricantes de computadoras. incluyendo a Digital Equipment Corporation (DEC), International Busiess Machines (IBM), American Telephone and Telegraph (AT&T), Sun Microsystems, y Hewlett Packard, habían participado en el desarrollo inicial de este sistema. Durante su corta vida X

2


Window se ha actualizado continuamente, y en este momento la versión más reciente es la XllR5 (Versión 11 edición 5).

%tema en

o , disco

L

Ethrmet

r

L

EstaEmn de Irabajo gráfka

Teeldo

I z I r I I I 1 I

Figura 1-1. Sistema X Window

Dispositivos flsicos (Hardware) Los sistemas X Window pueden ejecutarse sobre distintos dispositivos físicos. La unidad de salida es una pantalla gráfica, cuya resolución al menos es la de VGA. Los dispositivos de entrada más comunes son el teclado y el ratón. Otras unidades de entrada son la bola de tracción, la tableta digitalizadora y la pantalla táctil.

Estaciones de trabajo

La inmensa mayoría de los fabricantes de estaciones de trabajo soportan los sistemas X Window. La importancia de este mercado es tal que hasta diciembre de 1991 una sola compañía, Sun Microsystem, había vendido casi medio millón de estaciones de trabajo. La continua bajada de los precios de las estaciones de trabajo y el aumento de las necesidades de computación de los grupos y de los individuos significó una ampliación del ámbito de uso de las estaciones de trabajo y, por consiguiente, de los sistemas X Window.

Terminales X

La mayoría de las organizaciones no pueden permitirse el lujo de gastar 5.000 dólares o más en equipar cada despacho con una estación de trabajo completa. Una alternativa cada vez más utilizada es un Terminal X, que es un terminal gráfico sin disco en el que se ejecuta un único programa, el programa servidor X Window (X Window servir programa) que veremos más adelante en este mismo capítulo.

3


La rápida expansión del mercado X Window ha permitido el desarrollo de una amplia variedad de Terminales X, algunos de los cuales compiten con las estaciones de trabajo en memoria y CPU. Como estos Terminales X no tienen disco, son más baratos que las estaciones de trabajo equivalentes.

Otras de las ventajas de los Terminales X es el reducido mantenimiento del hardware y del software comparado con el de las estaciones de trabajo en las que se ejecutan sistemas X Window. Los Terminales X ofrecen un mayor control por parte del departamento de informática y permiten aprovechar la inversión realizada en grandes computadoras (mainframes).

Los Terminales X tienen potenciales desventajas, no pueden procesar datos donde y cuando son generados, y los modelos inferiores tienden a ser muy lentos. Bajo un punto de vista critico, los Terminales X representan un paso atrás hacia el mundo del tiempo compartido (Time Sharing).

Microcornputadoras

La cuestión estriba en: “Si los sistemas X Window son tan potentes, ¿podremos usarlos en nuestras microcomputadoras?”. La respuesta es “depende”.

Un requisito claro es la alta resolución gráfica, de forma que es preferible Super VGA a VGA o Hercules. Las necesidades de procesamiento pueden hacer demasiado baja la resolución de 1024 x 768. El color es una cuestión opcional, pero si lo elegimos, debemos aseguramos que los colores sean atractivos y variados. (Los usuarios actuales tienden a considerar los 16 colores un poco aburridos.)

El procesador mínimo es un 80486 o su equivalente (por ejemplo un 68030). (Los usuarios de AT pacientes pueden encontrar el tiempo de espera aceptable para gráficos simples.) Es absolutamente necesario disponer de un disco fijo grande y rápido. El sistema X Window no es como el DOS, no se haga la idea de poder confinarlo en un rincón de su disco fijo de 40 megabytes (m). Al menos hemos de dedicar un disco fijo de 500 Mb al sistema X Window y su entorno, UNIX incluido. Estudie sus manuales para determinar la configuración necesaria para su implementación del sistema X Window y las utilidades que necesite.

Como se trata detalladamente en este capítulo, los sistemas X Window incluyen dos tareas: ejecutar la aplicación de usuario y manejar gráficos. A menos de que disponga de un auténtico sistema operativo multitarea, su microcomputadora no podrá atender a la aplicación de usuario y a los gráficos. Una microcomputadora aislada con sistema operativo DOS tan sólo puede gestionar una de estas dos tareas, pero no ambas.

UNIX y otros sistemas operativos multitarea con frecuencia controlan grandes microcomputadoras. Por ejemplo, el Open Desktop de Santa Cruz Operation, mostrado en la Figura 1-2, se ha convertido en el sistema operativo UNIX estándar de las microcornputadoras de gama alta. Este paquete proporciona por completo todas las capacidades X Window. Podemos contar con que en el hturo muchos paquetes para grandes microcomputadoras soportarán parcial o totalmente X Window.

Todos los ejemplos que se darán más adelante, se han desarrollado sobre una microcomputadora compatible IBM 586/166 MHz con un monitor color gráfico de 1024 x 768, ejecutando el SCO Open Desktop Personal System Versión 2 con el Open Desktop Development System. El software utilizado incluía UNIX System V, X Window versión 11.4, con la utilidad OSFMotif y el lenguaje de programación C. No se preocupe, ya que el uso de un equipo o una implementación de X Window diferente no afectará a su comprensión. Realmente la clave de X Window es la flexibilidad.

4


Arquitectura ClientdServidor

El corazón de la filosofia X Window es la arquitectura clientehervidor. Esta arquitectura es el modelo del sistema X Window, mediante la que los clientes, o programas de aplicación, comunican con los servidores, o unidades de visualización a través de una red local. En la Figura 1-3 se muestra la arquitectura cliente/servidor. En esta sección se examinan detalladamente los componentes de la arquitectura ClienteJservidor de X Window y se compara esta arquitectura con el modelo clientehervidor para otros sistemas informáticos.

Figura 1-2. Las ventanas de SCO Open Desktop

Estación de trabaj o grS1ea

como savidor X

I I

f ' 1

~~

O

- -. Cornputadom c m cYentesX L I

Figura 1-3. Arquitectura cliente/servidor.

5


Cliente

Básicamente el cliente es el programa de aplicación. A diferencia de los programas gráficos tradicionales, los clientes X Window no se comunican directamente con el usuario. El cliente obtiene una entrada de usuario como, por ejemplo, la pulsación de una tecla o de un botón del ratón desde el servidor que es la otra parte de la arquitectura cliente/servidor. El cliente ejecuta las órdenes X Window que requiere el servidor para dibujar gráficos. Varios clientes pueden estar conectados a un Único servidor.

Servidor

En términos simples, podemos decir que el servidor es la unidad de visualización, que a su vez puede estar compuesta por varias pantallas físicas. El servidor ejecuta diversas funciones relacionadas entre sí:

0 Pasa la entrada de usuario a los clientes a los que está conectado. Ejemplos comunes de entradas de usuario son: el pulsar una tecla, o un botón del ratón, y el modificar la posición del puntero. Esta entrada es imprevisible, cualquier tipo de entrada puede ocurrir en cualquier orden.

0 Decodifica los mensajes de los clientes, como las peticiones de información o el movimiento de una o más ventanas. Estos requerimientos se expresan en un lenguaje formal X Window.

Mantienen las estructuras de datos complejas. El manejo de estas estructuras de datos por el servidor reduce las necesidades de almacenamiento y de procesamiento del cliente, y disminuye la cantidad de datos a transmitir a través de la red.

Conexión Una parte esencial del sistema X Window es el enlace físico entre el cliente (programa de aplicación) y el servidor (unidad de visualización). Los protocolos de red describen el formato y el orden de los datos, y controlan los bytes que componen un mensaje enviado desde un punto a otro de la red. Los programadores de X Window no necesitan conocer el protocolo de la red que se está usando. Normalmente se utilizan tres protocolos para la transferencia de datos entre el servidor y los clientes. Estos son: el TCP/IP desarrollado por la Universidad de California, DECNet desarrollado por Digital Equipment Corporation, y STREAMS desarrollado por AT&T. X Window se escribió de forma que el uso de éstos y otros protocolos fueran transparentes para el usuario.

Ethernet es una tecnología de comunicaciones de redes de área local muy usada. Suministra el canal de comunicación fisico necesario entre los clientes y el servidor. Transmite datos a un promedio de 1 millón de bits por segundo. Compare esta velocidad con la normalmente utilizada en la conexión entre un terminal gráfico y una computadora central que es de 19.200 bits por segundo. El enlace X Window puede transferir datos unas 50 veces más rápido (siempre que el número de colisiones, que disminuye la velocidad de transmisión, sea bajo en la red Ethernet).

Relacio'n con los sistemas tradicionales ClientdServidor

Muchas personas están familiarizadas con los términos "cliente" y "servidor", asociándolos con otros tipos de sistemas de computadoras. Por ejemplo, una red de área local almacena los archivos en un servidor de archivos, el cual centraliza la gestión de las operaciones de archivo de los usuarios (clientes). Un servidor de impresión encola las peticiones de impresión de los usuarios. En estos casos, el servidor se localiza sobre una computadora remota cargada con muchas tareas, y el cliente es el usuario. Los sistemas X Window invierten la localización de estos elementos, el servidor está situado en la computadora del usuario o terminal X, y el cliente en la computadora remota, a menudo cargada de tareas. Tanto los

6


tradicionales sistemas cliente/servidor como los sistemas X Window aplican el principio de división del trabajo al centralizar las tareas claves en el servidor, facilitando que el cliente se centre en su aplicación.

Software Para enviar los datos adecuados y los bytes de control desde el cliente al servidor y viceversa, se necesita un software especial. En el Capítulo 2, "El programa Hola Mundo", se muestra la complejidad de la visualización de una simple ventana en la pantalla del usuario. El primer programa ejemplo tiene un tamaño de dos paginas. La flexibilidad de X Window tiene su precio.

Este texto muestra cómo programar sistemas X Windows. Se introducen los tres niveles de programación, que van desde llamadas en lenguaje C que acceden directamente al protocolo X de la red, a paquetes comerciales parecidos a la interfaz gráfica de usuario Windows de Microsoft. En la Figura 1-4 se ilustran estos tres niveles de programación. ¿Cuál de estos tres niveles es el que deberíamos usar?. La respuesta es simple: un típico programa X Window debe usar en distinto grado los tres niveles, dependiendo de la naturaleza exacta de la tarea a realizar.

Aplicacibn I 1 c c I Herramienta X P r I 4 4

Xt Intrinsics A

I Xt Intrinsics

Protocolo X

Figura 1-4. Niveles de programación.

Funciones Xlib

La comunicación clientelservidor del sistema X Window se efectúa a través de un protocolo de red denominado protocolo X (X protocol). Este protocolo X define el número exacto de bytes que se necesitan para realizar todas las operaciones X Window, incluyendo el dibujo y movimiento de una ventana, o la reacción cuando se pulsa un botón del ratón. La programación con el protocolo X es en extremo ardua, este lenguaje de base no ofrece facilidades que ayuden al programador.

El protocolo X es similar al lenguaje máquina que normalmente se asocia a un determinado procesador. Pocas personas escriben programas en este lenguaje o en protocolo X, no es necesario hacerlo De la misma manera que el lenguaje ensamblador proporciona la potencia del lenguaje máquina con mucho menos esfuerzo, las funciones Xlib proporcionan la potencia del protocolo X con un coste menor.

7


Xlib es una biblioteca de funciones que proporciona unas 300 funciones en lenguaje C usadas para generar protocolo X.

Un ejemplo de una función Xlib es XCreateSimpleWindow. A pesar de su nombre esta función no es especialmente simple. Cuando utilizamos esta función en un programa X Window, el programador debe suministrarle nueve parámetros específicos que manejan valores como el tamaño de la ventana, su posición, y la anchura del borde. Las funciones Xlib son el punto inicial para aprender cómo trabaja X Window. En el Capítulo 2 se presenta un programa X Window compuesto por funciones Xlib. Aunque es esencial dominar las funciones Xlib para saber cómo trabaja el sistema X Window, normalmente deseará programar con órdenes de mayor nivel usando Xt Intrinsics o ciertas herramientas (conjunto de utilidades) en propiedad.

Xt Intrinsics

El X Toolkit Intrinsics, también conocido como Xt Intrinsics, permite a los programadores crear y usar bloques de pantalla estándar llamados Widgets, como por ejemplo menús, barras de desplazamiento, botones y cuadros de diálogo. Un uso cuidadoso de los widgets simplifica el proceso de programación con X Window. Quizá lo más importante es que da a la aplicación una apariencia estándar de fácil interpretación (ver y entender) y por tanto la hace más fácil de usar. Las funciones Xt Intrinsics comienzan con la mayúscula X seguida de la minúscula t. Por ejemplo, la función XtWindow(w) devuelve la ID (identificación) de la ventana asociada con el widget w. No adelante conclusiones al comparar la función Xlib XCreateSimpleWindow con la función Xt Intrinsic XtWidow(w), ya que no realizan las mismas acciones.

Herramientas en propiedad

El nivel más alto de programación para sistemas X Window es propietario. Las casas de software desarrollan sus propias utilidades como extensiones de la utilidad Xt Intrinsics. Las herramientas en propiedad incluyen características de personalización que prometen atractivas salidas, facilidad de uso, y un rápido desarrollo de aplicaciones. Un gestor de ventanas (Window manager) es un cliente especial responsable de manipular las ventanas en la pantalla. El sistema X Window incorpora dos gestores de ventanas: uwm y twn. Las herramientas en propiedad utilizan sus propios sistemas que son mucho más sofisticados. En el Capítulo 4, "Ventanas y técnicas de trabajo con ventanas", se tratarán con mayor detalle los gestores de ventanas.

Cada herramienta en propiedad produce un modelo de interfaz gráfica de usuario, que permite a los diseñadores crear una serie de aplicaciones con una apariencia estándar. Se hace necesario un aviso: es necesaria una considerable destreza para producir un interfaz realmente amigable, si lo es para una única aplicación, mucho más para una serie de aplicaciones. No importa la potencia de la herramienta o utilidad, la mala programación sigue siendo mala.

El dominio de la programación X Window requiere aprender el uso de tres productos interrelacionados: Nib , Xt Intrinsics y la herramienta en propiedad seleccionada. Igualmente importante es que el programador sepa cuándo usar cada uno de estos productos.

OSF/MofiJ: La Open Software Foundation (OSF) es un consorcio formado en 1988 por los mayores vendedores de hardware, incluyendo IBM, DEC y Hewlett Packard. La utilidad OSFMotif, con frecuencia llamada Motif, es la herramienta en propiedad X Window más usada. El gestor de ventanas mwm de Motif gestiona los detalles de la creación y procesamiento de ventanas. La Figura 1-5 muestra un ejemplo de ventanas con OSFIMotif.

8


Las funciones Motif comienzan con una letra mayúscula X seguida por una minúscula m. Por ejemplo, la función XmCreateMenu sitúa un menú desplegable (temporal) en la pantalla en la posición indicada por otra función Motif.

En este texto se presentan exclusivamente las utilidades OSFMotif. Sin embargo, es importante familiarizarse con el software de la competencia. El proceso de selección del producto es largo y supone importantes consecuencias para los programadores con X Window.

Open Look. El mayor competidor de OSFMotif es el interfaz gráfico de usuario Open Look, distribuido por la American Telephone & Telegraph (AT&T) y por Sun Microsystem. La versión de Sun incluye funciones que facilitan la conversión de aplicaciones anteriores de Sun al sistema X Window. En la Figura 1-6 se muestran ejemplos de ventanas creadas con el interfaz gráfico de usuario Open Look. En la Tabla 1-1 se muestran los fabricantes y otras compañías que soportan las utilidades Motif y Open Look.

Otras implementaciones. Quarterdeck Office Systems, el distribuidor del más vendido programa de gestión de memoria para MS-DOS y MS-Windows, ha presentado el DESQviewIX. Este paquete está destinado a dar a las microcornputadoras de gama alta una filosofía clientehervidor X Window para aplicaciones de red. En el mercado se encuentran disponibles potentes productos para microcomputadoras.

Figura 1-5. Típica interfaz gráfica de usuario con Motif

9


Figura 1-6. Típica interfaz gráfica de usuario de Open Look.

Tabla 1-1. Disponibilidad de Motif y Open Look.

Fabricante Motif

IBM Digital Equipment Corp. Hewlett Packard UNISYS Sun Microsystem Solbourne Compaq Dell Prime Data General Silicon Graphics MIPS NCR AT&T Wang NEC Hitachi Commodore

V V V V T V V V V V V V V V V V V

OpenLoock

T T T

V V

V

V

Otros sistemas de ventanas Este capítulo inboductorio termina examinando otros populares sistemas de ventanas, comparándolos y contrastándolos con el sistema X Window. Antes de examinar implementaciones particulares es esencial determinar los objetivos de esos sistemas.


Historia y objetivos Tanto los usuarios finales como los especialistas en computadoras encontraban dificil trabajar con 10s primeros sistemas, Durante años multitud de empresas y organizaciones de investigación han aplicado los desarrollos tecnológicos con el propósito de hacer las computadoras más fáciles de usar. Muchas de las utilidades y técnicas de las modernas computadoras se basan en trabajos anteriores a los años ochenta. Entre los ejemplos clave se incluyen la programación orientada a objetos, el Apple Macintosh, y las interfases gráficas de usuario con el ratón. Veamos a continuación los componentes básicos de los GUIs y después los compararemos con las implementaciones actuales de los sistemas X Window. Las interfases gráficas de usuario deberían proporcionar las siguientes posibilidades:

Uso extensivo de elementos de control visual estándares, como los iconos (icons) y las burras de desphzumiento (scroll bars). Los iconos son representaciones gráficas de objetos, por ejemplo un cubo de basura puede significar borrado de un archivo. Las barras de desplazamiento permiten al usuario desplazar los datos que aparecen en una ventana.

Manipulación directa de los elementos que hay en la pantalla. Por ejemplo, presionar un botón del ratón para modificar el margen de un documento hasta obtener el ancho deseado, en lugar de introducir un valor previamente calculado.

Consistencia a través de aplicaciones y plataformas. Los usuarios aprenden una sola vez la forma de imprimir. Cuando conocen cómo imprimir un documento, va saben como imprimir otros, independientemente de la aplicación y de la computadora utilizada.

Aplicaciones múltiples simultáneas. Por ejemplo, un usuario puede editar un documento y al mismo tiempo volver a calcular una hoja de cálculo. Conforme la computadora recalcarla la hoja de cálculo, la versión actualizada aparece automáticamente en el documento.

Con un sistema atractivo y fácil de usar. Un usuario contento es más productivo. Idealmente los usuarios deberían poder personalizar su GUI para adaptarla mejor a su trabajo, en lugar de tener que acomodarse a la forma de hacer las cosas de la interfaz gráfica de usuario (GUI).

Implementaciones

Ninguna de las interfases gráficas de usuario existentes actualmente cumplen todos los objetivos indicados anteriormente. Sin embargo varios de los GUls más usuales cumplen muchas de ellas.

Macintosh Finder

El Apple Macintosh es una de las computadoras desarrolladas desde un principio con una interfaz gráfica de usuario. Como la filosofía GUI fue parte de su diseño original, mucha gente encontró que estas computadoras eran más fáciles de usar que los compatibles IBM. No es éste un lugar para entrar en la polémica IBM-Macintosh, pero el sector del mercado que deseaba una microcomputadora fácil de usar prefería los Macintosh. Sin embargo el Macintosh Finder no ofrece la potencia de gestión de ventanas y la flexibilidad de los sistemas X Window. Aparte de esto, tanto la versión UNIX como los sistemas X Window estándar están disponibles en los Macintosh.

11


Microsofi Windows

Microsoft Windows o MS-Windows, se ha convertido en el estándar GUI de los sistemas compatibles IBM. Habiendo aparecido el mes de noviembre de 1985, las ventas de este producto se dispararon con la versión 3.0 lanzada en mayo de 1990. Cientos de las populares aplicaciones DOS se ejecutan actualmente sobre este entorno. La configuración recomendada para trabajar en este entorno consiste en una computadora con un microprocesador 486, O preferiblemente un 586 , con al menos 8 Mb de memoria RAM para los usuarios que ejecutan un solo programa a la vez, y de 16 Mb para multitarea, y un monitor gráfico SVGA. En la Figura 1-7 se muestra Microsoft Windows.

Figura 1-7. Típica interfaz gráfica de Microsoft Windows

OW2 Presentation Manager

En abril de 1987, IBM lanzó la sene de microcomputadoras PS/2, muchas de las cuales corren bajo el sistema operativo OS!2. Presentation Manager (PM) fue el GUI estándar de las primeras versiones del OS/2. Su apariencia es bastante similar a la del MS-Windows. La influencia futura de 0 9 2 y el PM no esta clara, debido en parte a las cambiantes relaciones entre I BM y Microsoft.

El sistema DESQview

Estrictamente hablando, DESQview no es un GUI ya que no se ejecuta en modo gráfico. Sin embargo, proporciona una alternativa a MS-Windows tanto para las microcomputadoras del tipo XT como las superiores. DESQview admite como unidad de entrada tanto el ratón como el teclado, proporciona tanto

12


ventanas como multitarea, e incluso ejecuta MS-Windows. La anunciada versión DESQview/X promete ejecutar sistemas X Window en compatibles IBM.

NeXTstep

La computadora NeXT diseñada por Steve Jobs, uno de los dos creadores del Apple, alardea de disponer de un sofisticado sistema de ventanas llamado NeXTstep. Este sistema contiene varias características interesantes, tales como visualización PostScript, una interfaz MIDI para la generación de música, y un inmenso disco óptico, valiosísimo para las aplicaciones multimedia. Todos los programas que se incluyen en los siguientes capítulos, se probaron en una computadora NeXT basada en. el microprocesador 68040.

Analogías y diferencias

Los sistemas X Window y las interfases gráficas de usuario (GUls) para microcomputadoras, tienen el mismo objetivo básico: facilitar el uso de la computadora. Todos proporcionan elementos gráficos, por ejemplo iconos y barras de desplazamiento, para comunicarse con el usuario. Herramientas en propiedad como OSFMotif que modifican los sistemas X Window en GUls. De hecho, los widgets de OSFMotif se han diseñado para parecerse a MS-Windows.

Existen importantes diferencias entre los sistemas X Window y las GUls basados en microcomputadoras. Los diseñadores de sistemas X Window que se limitan a utilizar las librerías Xlib y Xt Intrinsics pueden crear una interfaz con una apariencia propia, en lugar de trabajar con la idea que otra persona tiene de una interfaz ideal. Los sistemas X Window normalmente funcionan sobre estaciones de trabajo para Ingeniería y científicos, más potentes que las microcornputadoras de gama alta. Se pueden usar con terminales X y computadoras de todos los tamaños, desde los compatibles AT a las supercomputadoras. Finalmente, los sistemas X Window se han diseñado pensando en las redes de computadoras. Un servidor puede visualizar los gráficos generados por diversas computadoras conectadas a la red.

13


Puntos clave

2 En qué consiste el sistema X Window ?

El "sistema X Window" (también llamado X Window y en otras ocasiones, aunque erróneamente X Windows), se ha convertido en la herramienta software estándar utilizada para el desarrollo de interfases gráficas de usuario (GUIs) sobre estaciones de trabajo. Debido a la independencia de dispositivo, las interfases gráficas de usuario desarrolladas en una computadora, pueden ser ejecutadas sin problemas en otras distintas.

El sistema X Window

El sistema X Window se ha convertido en un sistema de ventanas estándar independiente del hardware y del sistema operativo. Se trata de una utilidad desarrollada para sistemas gráficos de alta resolución tanto en color como en monocromo.

Hardware

Los sistemas X Window se pueden ejecutar en gran variedad de dispositivos hardware. La unidad de salida es una pantalla gráfica, con una resolución VGA como mínimo. Los dispositivos de entrada comúnmente utilizados son el teclado y el ratón. La gran mayoría de los fabricantes de estaciones de trabajo soportan los sistemas X Window. Una alternativa que se está popularizando cada vez más son los terminales X, un terminal gráfico sin disco que ejecuta un Único programa, el servidor X Window. También hay disponibles sistemas X Window en las microcomputadoras de gama alta. El Open Desktop de Santa Cruz Operation System se ha convertido en el estándar para las microcornputadoras con sistema operativo UNIX. Este paquete proporciona todas las características de X Window.

Arquitectura Cliente/Servidor

El núcleo de la filosofía X Window es la arquitectura clientehervidor. Esta arquitectura es el modelo del sistema X Window mediante el cual los clientes, o programas de aplicación, se comunican con los servidores, o unidades de visualización a través de la red.

A diferencia de los programas gráficos tradicionales, los clientes X Window no se comunican directamente con el usuario. El cliente recibe la entrada del usuario, normalmente la pulsación de una tecla o la presión sobre el ratón mediante el servidor, la otra mitad de la arquitectura clientehervidor. El cliente ejecuta las órdenes X Window que necesita el servidor para dibujar gráficos. Varios clientes pueden estar conectados a un Único servidor.

En término mas sencillos, el servidor es la unidad de visualización, la cual puede estar constituida por varias pantallas. El servidor ejecuta diversas funciones relacionadas entre sí: pasa las entradas de usuario a los clientes. Descodifica los mensajes de los clientes, como peticiones de información o movimientos de una o varias ventanas. Mantiene las estructuras de datos complejas, reduciendo las necesidades de procesamiento y de almacenamiento de los clientes y disminuyendo la cantidad de datos a transmitir a través de la red.


Conexiones

Una parte esencial de los sistemas X Window es el enlace fisico entre el cliente (programa de aplicación) y el servidor (monitor). Los protocolos de red describen el formato y orden de los datos, y los bytes de control que componen un mensaje enviado desde un punto a otro de la red. Los programadores X Window no necesitan conocer el protocolo de red que se está usando. Los tres protocolos de comunicación de datos más comunes son: TCP/IP, DECNet y STREAMS.

Sofhgare

Para enviar de forma correcta datos e información de control desde el cliente al servidor y viceversa se necesitan programas especiales. La comunicación clientehervidor en un sistema X Window se realiza a través del protocolo de red, denominado protocolo X. Los expertos en programación X Window deben conocer tres productos interrelacionados: Xlib, Xt Intrinsics y la herramienta en propiedad que hayan elegido. De la misma importancia es saber cuando utilizarlos.

Xlib es una biblioteca de unas 300 funciones escritas en lenguaje C usadas para generar el código que cumple el protocolo X, el cual impone un complejo conjunto de requisitos. Xlib reduce en gran medida la dificultad de la programación X.

Xt Intrinsics es una utilidad que proporciona X Window que permite construir bloques, como por ejemplo menús, barras de desplazamiento y cuadros de dialogo, ayudando a conseguir interfases de aplicación más consistentes.

De otro lado las herramientas en propiedad generadas por terceras partes proporcionan sus propias extensiones a las utilidades X incluyendo normalmente sus propios gestores de ventanas. La herramienta más usada es OSFPMotif, de la Open Software Foundation (OSF), un consorcio creado en 1988 por los grandes fabricantes de hardware, entre ellos IBM. DEC y Hewlett Packard.

El mayor competidor de OSF/Motif es la interfaz gráfica de usuario Open Look, distribuida por AT&T y Sun Microsystems.

Interfases gráficas de usuario

Las interfases gráficas de usuario proporcionan una alternativa gráfica fácil de usar frente a las molestas interfases de texto que hacían dificil el uso de los primeros sistemas con computadoras. Una interfaz gráfica de usuario debería proporcionar las siguientes posibilidades:

Uso extensivo de elementos de control visual estándar, como por ejemplo iconos y barras de desplazamiento.

0 Manipulación directa de los elementos que están en la pantalla.

Consistencia a través de aplicaciones y plataformas.

0 Aplicaciones múltiples simultáneas.

0 Sistema atractivo y fácil de usar.

15


Actualmente no existe ningún entorno gráfico de usuario que ofrezca todas las posibilidades anteriores. Las interfases (GUIs) mas populares son Macintosh Finder y Multifnder, Microsoft Windows (MS-Windows), OS/2 Presentation Manager, Quarterdeck Office System DESQview, y NeXTstep.

16

Elprograma “Hola Mundo”

Capítulo 2

El programa YHola Mundo” Tradicionalmente, el primer programa que se estudia cuando se aprende el lenguaje C, se llama “Hola Mundo” (“Hello World”). Este sencillo programa llama a una función C que imprime la cadena de caracteres “Hola. Mundo” en la salida estándar de la computadora (un terminal, a menos que se especifique otro destino).

main() {

1 printf(“\n Hola Mundo”);

En este capítulo se presenta un programa similar, escrito para sistemas X Window. Al principio parece algo complicado para ser un programa de iniciación, pero esto es inevitable, ya que X Window tiene mucho que hacer. El programador de X Window debe especificar detalladamente muchos pasos que los programadores de lenguaje C o de cualquier otro lenguaje de alto nivel darían por dados. El resultado es un programa claramente diferente, que no necesita ser modificado cada vez que cambie la computadora. Puede que ahora no lo comprenda todo. No se preocupe, ya que en los próximos capítulos veremos todos los puntos importantes en detalle. Puede escribir el programa, y a continuación compilarlo y enlazarlo mediante un archivo make (makefile) como el que se encuentra al final de este capítulo. Una vez que haya conseguido que se ejecute el programa pruebe a hacer modificaciones simples, y vera como van encajando las piezas.

Funciones X Window En el programa “Hola Mando” que viene al final de este capítulo se incluyen las funciones X Window que son necesarias como mínimo para generar una salida a través de la pantalla. Por supuesto, los programas realmente útiles serán mucho más complicados. Este programa contiene únicamente funciones Xlib, y no hace referencia ni a Xt Intrinsics, ni a ninguna herramienta como OSFMotif. El programa “Hola Mundo” realiza las siguientes operaciones (algunas de ellas necesitan más de una línea de código):

Identifica los archivos de cabecera apropiados y realiza las declaraciones correspondientes del programa.

Establece una conexión con la estación de trabajo. Con este paso se establece un enlace entre el programa de aplicación (cliente) y la unidad de visualización (servidor).

Crea una ventana en la pantalla. La función XCreateSimpleWindow utiliza nueve parámetros para indicarle a X Window cómo y dónde debe colocar la ventana. Esta función genera un identificador de ventana Único que el usuario debe grabar por si se hacen más adelante referencias a é1 dentro del programa.

Notifica a las otras aplicaciones de la estación de trabajo la creación de la nueva ventana. Recuerde que X Window puede procesar múltiples aplicaciones sobre la misma pantalla.

17

El programa "Hola Mundo"

Crea un contexto gráfico (graphics context) para la ventana. Un contexto gráfico es una estructura que contiene información acerca de los colores, los tipos de letra y anchura de las líneas.

Selecciona el tipo de suceso de entrada a procesar. Un suceso (event) es una estructura que envía el servidor y que describe un hecho que acaba de ocurrir, debiendo la aplicación seleccionar si procesarlo o no. Los sucesos son un concepto fundamental en sistemas X Window.

Visualiza la ventana. Visualizar la ventana (mapping a window) significa hacer visible la ventana en la pantalla. Esta actividad está separada y se realiza a continuación de la creación de la ventana.

Ejecuta el bucle principal. El núcleo de un programa X Window es un bucle que lee y procesa sucesos, generando salidas cuando se requiere. Esta parte del programa realiza el verdadero trabajo de la aplicación. Los programas X Window deben estar preparados para procesar cualquier suceso (cuyo tipo haya sido previamente seleccionado) procedente de cualquier cliente en cualquier momento. No se extrañe de que los programas X Window sean complicados.

Finaliza el programa. En este punto, el programa deja de ejecutarse y devuelve los recursos al sistema.

Examen del programa "Hola Mundo

En esta sección describimos una versión lo más simple posible del programa "Hola Mundo" escrita con funciones Nib. Para hacerlo más legible las llamadas a las funciones Xlib se escriben en negrita. Al final del capítulo se muestra el listado completo del programa.

Inclusión de los archivos de cabecera En la programación en lenguaje C se utiliza la directiva #include para acceder a un conjunto de declaraciones y constantes predefinidas situadas en unos archivos llamados cabeceras (headers). El preprocesador une la cabecera (#include) al código del programa fuente. X Window usa sus propios archivos de cabecera, como los que se muestran a continuación:

#include <X1 l/Xlib.h> #include <Xll/xutil.h>

Declaraciones Con el lenguaje de programación C se utiliza la directiva Mefine para asociar un nombre significativo y definido por el programador a una construcción del lenguaje C. Esta directiva genera programas más fáciles de comprender. En el siguiente ejemplo definimos el valor 1 como TRUE (VERDADERO) y el valor O como FALSE (FALSO).

#define TRUE 1 #define FALSE O

Las siguientes declaraciones referencian e inicializan tres cadenas de caracteres. La primera cadena contiene el mensaje de salida, la segunda identifica un nombre de uso interno, y la tercera define el nombre de ventana que aparecerá en la parte superior de la ventana de salida

18


char hellow[] = "Hola-mundo"; char theiconname[] = "Helloi"; char thewindowname[] = "hola";

El lenguaje de programación C requiere una única función main que indique cuál es la primera función ejecutable del programa El parámetro argc señala al número de argumentos de la línea de ordenes. El parámetro argv se corresponde con un puntero a una lista de cadenas de caracteres que contiene los argumentos de la línea de órdenes.

main (argc, argv) int argc; char *argv(]; {

Las instrucciones siguientes son propias de los programas X Window.. Declaran el monitor a abrir y la ventana que aparece en él. El identificador *thedisplay es un puntero a una estructura de datos que gestiona la conexión con la estación de trabajo. El elemento thewindow identifica el recurso ventana, y el elemento thegc identifica el contexto gráfico. Las estructuras de datos asociadas con thewindow y fhegc deben ser accesibles durante toda la aplicación. El elemento theevent se corresponde con una compleja estructura de datos que contiene información asociada con cada uno de los sucesos de entrada de datos detectado por el servidor. El elemento thekey identifica la tecla pulsada cuando ocurre un suceso asociado al teclado. El elemento thehint se corresponde con la estructura de datos mediante la que el programa informa a las demás aplicaciones acerca de esta ventana.

Display *thedisplay; Window thewindow; GC thegc; XEvent theevent; KeySym thekey; XSizeHints thehint;

Con las instrucciones siguientes se declaran las variables C usadas en la implementación X Window:

int thescreen; unsigned long theforeground, thebackground; char thebufferls]; int keycount; int finished;

Establecimiento de la conexión La primera función Xlib que aparece con cualquier programa es

thedisplay = XOpenDisplay(" ");

Esta función establece un enlace de red entre la aplicación (cliente) y la estación de trabajo (servidor) y coloca la información que describe esta conexión en la estructura de datos a la que apunta el puntero thedisplay. El argumento vacío (" ") hace que el sistema busque el nombre de la pantalla en una variable de entorno denominada DISPLAY.

Creacih de una ventana La línea

19

El programa “Hola Mundo”

thescreen = DefaultScreen(thedisp1ay);

identifica la pantalla por omisión de la unidad de visualización. X Window puede usarse con unidades de visualización que consten de varias pantallas físicas. Por ejemplo, una pantalla color y otra monocromática.

thebackground = Whitepixel (thedisplay, thescreen); theforeground = Blackpixel (thedisplay, thescreen);

Este par de macros C identifica los valores de los puntos (pixels) asociados con el color del fondo y del primer plano (background and foreground) de la pantalla. El fondo no tiene porque ser blanco, y el primer plano no tiene porque ser negro. La estructura de datos a la que apunta thedisplay incluye estos valores de los puntos (pixels). Si cambiamos el monitor de la estación de trabajo el programa toma en cuenta automáticamente los nuevos valores para los puntos, manteniendo la compatibilidad.

Los campos de la estructura de datos de la variable thehint (que es del tipo XSizeHints) contienen los valores que describen la ventana al gestor de ventanas, como sigue:

thehint.x = 100; thehint.y = 150; thehint.width = 275; thehint.height = 120; thehint.flags = PPosition 1 PSize;

Los elementos thehint.x y thehint.y muestran la posición de la esquina superior izquierda de la ventana: 100 puntos a la derecha (valor x) y 150 puntos hacia abajo (valor y), respecto de la esquina superior izquierda de la pantalla.

Como estos dos elementos están íntimamente relacionados, pueden colocarse en la misma línea de programa. Los elementos thehint.width y thehint. height indican la anchura y la altura de la ventana, medida en puntos. El elemento thehint.Jags indica la posición y el tamaño preferidos para la ventana. Las siguientes funciones Nib solicitan al servidor la creación de la ventana.

thewindow = XCreateSimpleWindow (thedisplay, DefaultRootWindow (thedisplay), thehint.x, thehint.y, thehint.width, thehint.heigth, 7, theforeground, thebackground);

La función XCreateSimpleWindow devuelve el identificador de la ventana dada mediante la variable thewindow. Esta función incluye nueve parámetros, que deben escribirse ordenados: el identificador de ventana, la ventana padre (en este caso, la ventana raíz, que ocupa la pantalla completa), la posición x e y de la ventana, la anchura y altura de la ventana, la anchura del borde en puntos, el color del borde o del primer plano, y el color dei fondo.

Nota. Todos los parámetros se han definido antes de llamar a la función.

Notificación a las demás aplicaciones La función Xlib

XSetStandardProperties(thedisplay, thewindow, thewindowname, theiconname, None, argv ,argc, &thehint);

20


~~ ~

permite a una aplicación informar al gestor de ventanas de sus preferencias (&thehint), incluyendo 10s argumentos de la línea de órdenes (urgc y urgy). La función hace referencia al nombre de la ventana previamente definido (thewindowname).

Creación de un contexto gráfico La función Xlib

thegc = XCreateGC (thedisplay, thewindow, O, O);

crea un contexto gráfico con los valores por omisión.

Las dos funciones siguientes establecen los valores para el fondo y para el primer plano del contexto gráfico.

XSetBackground (thedisplay, thegc, thebackground); XSetForeground (thedisplay, thegc, theforeground);

Selección del tipo de suceso de entrada a procesar Con la función Xlib

XSelectInput (thedisplay, thewindow, (keyPressMask I ExposureMask));

se le pide al servidor que informe a la aplicación cuando se pulse una tecla mientras el cursor está en su ventana. La aplicación también realizará sucesos Expose (Exposición), que informan al cliente de que su ventana ha sufrido un cambio. Por ejemplo, si la ventana A está oculta por la B, y desaparece la ventana B, se produce un suceso Expose, de forma que la aplicación deberá volver a dibujar parcial o totalmente la ventana A, como se explica detalladamente en el Capítulo 4, Ventanas y técnicas de trabajo con ventanas".

Visualización de ventanas La función Xlib

XMapRaised (thedispLay, thewindow);

visualiza la ventana en la pantalla, encima de todas las ventanas existentes. Esta función envía un suceso Expose al programa para que redibuje la ventana cada vez que deja de estar cubierta. Por ejemplo, cuando desplazamos una ventana que la tapaba. Para aceptar tales sucesos Expose se incluye la función XSelectlnput.

Ejecución del bucle principal A la variable lógicafinished (final) se le da inicialmente el valor FALSE (FALSO) de forma que el bucle WHILE (MIENTRAS) se ejecute al menos una vez. Este bucle contiene las principales actividades de procesamiento del programa. Solicita un suceso, visualiza la cadena "hola-mundo" en la ventana, y acepta una entrada desde el teclado si el ratón está en el área de la ventana o si se presiona el botón izquierdo del ratón. El programa termina si el usuario pulsa la tecla "q". Inicialmente se le asigna a la variablefinished. FALSE, con la siguiente línea se hace que el bucle se repita mientrasfinished sea igual a FALSE. El bucle al menos se ejecuta una vez.

21


finished = FALSE; while (finished == FALSE) {

La función XNextEvent espera hasta que el servidor detecte un suceso de un tipo ya seleccionado con la función XSelectlnput.

Nota. Esta y las líneas que vienen a continuación se encuentran indentadas, indicando de esta forma SU inclusión en la sentencia while.

XNextEvent (thedisplay, &theevent);

La sentencia switch dirige los sucesos seleccionados a la sección apropiada del programa.

switch (theevent.type) {

Procesamiento de los sucesos Expose El código que existe entre las líneas case Expose y break se ejecuta solamente cuando se producen sucesos Expose. Los demás sucesos son procesados por las siguientes instrucciones case. Un valor cero en la variable theevent.xexpose.count se da en dos casos: o se produce un ímico suceso Expose, o se produjo el último de una serie de sucesos Expose asociados. El programa “Hola Mundo” ignora todos los sucesos Expose anteriores al último suceso de un grupo dado.

La función XDrawlmageString incluye siete parámetros. El programador debe especificar ordenadamente: la pantalla, la ventana, el contexto gráfico, el desplazamiento horizontal y vertical (medidos en puntos) del primer carácter del texto, el identificador de la cadena de caracteres a dibujar, y la longitud de esta cadena de caracteres. Cada vez que se produce un suceso Expose se vuelve a dibujar esta cadena.

case Expose: if (theevent.xexpose.count = O)

XDrawImageString (theevent.xexpose.display, theevent, xexpose.window, thegc, 205,65, hellow, strlen(hel1ow);

Procesamiento de cambios en la configuración del teclado Aunque no se han seleccionado explícitamente sucesos relacionados con la configuración del teclado, este código se incluye inicialmente en todos los programas. A continuación se muestra una pequeña rutina que protege el programa de modificaciones imprevistas en la configuración del teclado.

case MappingNotify;

break; XRefreshKeyboardMappin(&theevent);

22


Procesamiento de las entradas de teclado

El código que a continuación se muestra, se ejecuta cuando los usuarios pulsan cualquier tecla. La función XLookupString obtiene de las teclas pulsadas una cadena de caracteres y calcula su longitud, que frecuentemente, aunque no siempre, es 1. Si el primer carácter de la cadena es una letra “q! minúscula, se le asigna a la variablefinished el valor TRUE (VERDADERO), acabando así el bucle y el programa. Esto es lo que hace el siguiente programa.

case Keypress: keycount = XLookupString (&theevent, thebuffer,

8, &thekey, O); if ((keycount = 1) && (thebuffer[O] = ’9’))

finished = TRUE; break;

Terminación del programa

Las dos llaves de cierre (}) del segmento de código que se muestra a continuación se corresponden con las dos llaves de apertura que aparecen anteriormente en el programa. Observemos el uso de comentarios encerrados entre los símbolos I* y *l. Es conveniente escribir comentarios en los programas sobretodo cuando se programa con X Window.

} /* switch (theevent.type) */ } /* while (finished FALSE) */

Las tres funciones siguientes eliminan el área de contexto gráfico y la ventana, cancelan la conexión entre el servidor y el cliente, y por último detienen el programa.

XFreeGC (thedisplay, thegc); XDestroyWindow (thedisplay, thewindow); XCloseDisplay (thedisplay); } I* main *I

Al final del capítulo se ofrece el programa “Hola Mundo” completo.

Modificaciones posibles Aunque parezca largo, este programa es tan sólo el comienzo de la programación X Window. Ahora que conocemos lo que contiene el programa, vamos a considerar algunos de los elementos que faltan. Para comenzar, sabemos que el usuario termina el programa al pulsar una letra “q” minúscula; pero, ¿cómo sabe el usuario que se debe pulsar esa tecla?. Este programa no visualiza ningún mensaje que lo indique. Está claro que lo que se necesita es otra ventana o estructura alternativa que lo indique, por ejemplo un widget. La visualización de un mensaje en una estructura puede ser directa, pero la creación de otra ventana es más complicado, es necesario describir la relación entre las dos ventanas. Existen grandes diferencias entre crear dos ventanas adosadas, dos ventanas solapadas, o una ventana dentro de otra.

Aunque esta versión del programa “Hola Mundo” no haga uso del ratón, éste es el dispositivo de entrada principal de X Window. Es claramente deseable gestionar la entrada de datos procedente del ratón. ¿Cómo se maneja el cursor cuando por ejemplo se entra o se sale de la ventana?

23

- ” .”” . . _. .- . . . . . . . ” . ”


Este programa no tiene en cuenta los posibles errores. Por ejemplo, ¿qué haríamos si la función XOpenDisplay no puede establecer la conexión con la red?, ¿y si el usuario elige los mismos colores para el fondo que para el primer plano?

Código fuente del programa “Hola Mando ”

A continuación mostramos el listado completo del programa “Hola Mundo”.

I* Archivos de cabecera *I #include <Xll/Xlib.h> #include <X1 l/Xutil.h>

/* Declaraciones */ #define TRUE 1 #define FALSE O char hellow[] = “hola-mundo”; char theiconname[] = “Helloi”; char thewindowname[] = “hola”;

main(argc, argv) int argc; char *argv[]; 1

/* Declaraciones *I Display *thedisplay; Window thewindow; GC thegc; XEvent theevent; Keysym thekey; XSizeHints thehint; int thescreen; unsigned long theforeground, thebackground; char thebuffer[8]; int keycount; int finished;

I* Establecimiento de una conexi6n *I thedisplay = XOpenDisplay(“”);

/* Preparaci6n y creaci6n de una ventana *I thescreen = Defaultscreen (thedisplay); thebackground = Whitepixel thedisplay, thescreen); theforeground = BlackPixel (thedisplay, thescreen); thehint.x = 100; thehint.height = 120; thehint.flags = PPosition I PSize; thewindow = XCreateSimpleWindow (thedisplay,

DefaultRootWindow (thedisplay), thehint.x, thehint.y, thehint.width, thehint.height, 7, theforeground, thebackground);

I* Notificaci6n a las demhs aplicaciones *I XSetStandardProperties (thedisplay, thewindow, thewindowname,

theiconname, None, agrv, argc, &thehint);

24

Elprograma 'Hola Mundo"

/* Creacien de un contexto grfifico * I thegc = XCreateGC (thedisplay, thewindow, O, O); XSetBackground (thedisplay, thegc, thebackground); XSetForeground (thedisplay, thegc, theforeground);

/* Seleccidn del tipo de suceso de entrada a procesar */ XSelectInput (thedisplay, thewindow, (keyPressMaks 1 ExposureMask));

I* Visualizaci6n de las ventanas *I XMapRaised (thedisplay, thewindow);

I* Ejecuci6n del bucle principal *I finished = FALSE; while (finished = FALSE) {

XNextEvent (thedisplay, &theevent); switch(theevent.type) {

/* Procesamiento de sucesos Expose */ case Expose:

if (theevent.xexpose.count = O) XDrawImageString (theevent.xexpose.display, theevent.xexpose.window, thegc, 105,65, hellow, strlen (hellow));

break;

/* Procesamiento de cambios en la configuraci6n del teclado * I case MappingNotfy;

break; XRefreshKeyboardMapping (&theevent);

/* Procesamiento de las entradas del teclado */ case Keypress:

keycount = XLookupString (&theevent, thebuffer, 8,

if ((keycount == 1) && (thebufferlo] == '9')) &thekey, O);

I* Fin del programa * I finished = TRUE;

break; } /* switch (theevent.type) */

} I* while (finished = FALSE) */ XFreeGC (thedisplay, thegc); XDestroyWindow (thedisplay, tehwindow); XCloseDosplay (thedisplay); } /* main */

En la Figura 2- 1 se muestra la salida de este programa.

El sistema operativo UNIX dispone de la orden make. que llamando a un archivo MAKE, procesa el código fuente del programa. enlaza las bibliotecas necesarias y por último. crea un programa ejecutable. A continuación mostramos el listado del archivo MAKE para el programa "Hola Mundo", tal y como se ejecutaría bajo el sistema SCO ODT X Window. Este archivo será diferente para otros sistemas; así por ejemplo, el SCO necesita la biblioteca -1PW de la quinta línea pero no es así con otros sistemas UNIX. RM=rm-f cc = cc CFLAGS = -0 INCLUDES = -I. -Uusr/include -I/usr/iclude/Xll LIBS = -1Xm -1Xt 4 x 1 1 -1socket -1malloc -1PW .c.o: w w %@

25


$(CC) -C $(FLAGS) $(INCLUDE) $*X alkhellow hellow: he1low.o

$(CC) ”o $@ $(FLAGS) hel1ow.o $(LIBS) @echo Termina de la ejecuci6n del archivo de construccidn de hellow

$(RM) $@

Figura 2-1. Salida dei programa “Hola Mundo”

Puntos clave El primer programa Tradicionalmente el primer programa que se ve al estudiar el lenguaje de programación C es el conocido por “Hola Mundo”. Este simple programa llama a una función C que visualiza la cadena de caracteres “hola-mundo” en el dispositivo de salida estándar (un terminal, a menos que se especifique otro).

26


main0 {

I printf(“\n Hola Mundo”);

Funciones de un programa X Window

El programa “Hola Mundo” incluye un mínimo número de funciones X Window necesarias para producir una salida en la pantalla. en concreto, realizan las siguientes funciones:

Identificar los archivos de cabecera predefinidos correspondientes y realizar las declaraciones propias del programa

Establecer un enlace con la estación de trabajo.

Crear una ventana en la pantalla.

Informar a las demás aplicaciones que se están ejecutando en la estación de trabajo de que se acaba de crear una ventana.

Crear un contexto gráfico (GC) para la ventana. Un contexto gráfico es una estructura que contiene información acerca de los colores, tipos de letra y anchura de las líneas.

Seleccionar el tipo de suceso de entrada que se va a procesar. Un suceso es una estructura de datos que envía el servidor para describir un hecho que acaba de producirse, la aplicación debe elegir si procesarlo o no.

Visualizar la ventana, es decir hacerla visible en la pantalla.

Ejecutar el bucle principal del programa. El núcleo de un programa X Window es un bucle que lee y procesa los sucesos, generando las salidas que sean necesarias.

Finalizar el programa.

Modificaciones posibles

El programa “Hola Mundo”, funcionará tal y como se ha escrito, pero seria mas útil con algunas modificaciones. El usuario termina la ejecución del programa introduciendo la letra “q” minúscula, pero éste no presenta ningún mensaje que le informe de este hecho. Está claro que necesitamos otra ventana o estructura alternativa, por ejemplo un widget, con el mensaje correspondiente. También se puede incorporar a esta versión del programa la entrada desde ratón. Por último, este programa ni informa al usuario cuando se produce un error ni dispone de rutinas de manipulación de errores.

El siguiente paso a dar es profundizar en la comprensión de la terminología, conceptos, y técnicas de gestión de ventanas básicos X Window. Estos son los objetivos de los dos capítulos siguientes.

27

Conceptos básicos y terminología

Capítulo 3

Conceptos básicos y terminología Ahora que hemos visto un programa X Window completo, aunque no muy práctico, estamos preparados para abordar la programación X Window con mayor detalle. En este capítulo se presentan los conceptos y terminología que servirán de fundamento a la programación.

Recordemos que actualmente la comunicación entre el servidor y el cliente se produce vía el protocolo X. Los mensajes del protocolo se clasifican en cuatro tipos: peticiones del cliente al servidor, respuestas del servidor al cliente, mensajes de error cuando la petición no se completó con éxito, y mensajes de sucesos, que informan al cliente interesado de que se tomó una acción. Cada uno de estos tipos de mensajes tiene su formato propio y particular.

El programa "'Hola Mundo" del Capítulo 2, "E1 programa Hola Mundo", utiliza diversos archivos #include que proporcionan a los programas X Window una gran cantidad de utilidades. La versión 11, revisión 5 de X Window contiene 13 archivos #include que permiten a los programadores acceder a útiles servicios: por ejemplo, tipos de letra escalables e internacionales. Como existen alrededor de 300 funciones Xlib, necesitamos familiarizamos con la nomenclatura Xlib y los convenios para los argumentos. Algunos de los objetos procesados por las funciones Xlib son recursos almacenados en el servidor X. Estos recursos incluyen ventanas (Windows), contextos gráficos (graphics contexts), tipos de letra (fonts), cursores (cursors), mapas de colores (colormaps), y mapas de puntos (pixmaps). El uso correcto de los recursos reduce tanto el esfuerzo de codificar como el volumen de datos transferidos entre el cliente y el servidor.

El núcleo del sistema X Window es el procesamiento de sucesos. Aún a riesgo de simplificar excesivamente, los sucesos informan a los clientes interesados de que algo importante ha ocurrido. El sistema X Window proporciona 33 sucesos diferentes, clasificados en 10 categorías. Este capítulo identifica cada suceso y lo describe brevemente. Los capítulos posteriores proporcionan más detalles acerca de los sucesos más relevantes.

El protocolo X

Como muestra la Figura 3-1, el sistema X Window intercambia datos entre el servidor (unidad de visualización) y el cliente (programa de aplicación) vía el protocolo X, una doble vía de comunicación. El cliente y el servidor no necesitan ejecutarse sobre la misma computadora. Utilizar el protocolo X es similar a programar en lenguaje máquina Los usuarios finales no necesitan conocer los detalles del protocolo X. Los programadores de aplicaciones cuentan con funciones Xlib, Xt Intrinsics, herramientas en propiedad, o una combinación de todas estas facilidades para crear aplicaciones, que no hacen referencia directa al protocolo X. Sin embargo, es importante tener un conocimiento básico de lo que ocurre en sus aplicaciones. Este conocimiento incrementa la eficiencia de las aplicaciones y reduce la probabilidad de error tanto en el diseño como en la codificación.

29


Cliente Cliente

t t Red local

A Protocolo de RedX

i Figura 3-1. Arquitectura Cliente/Servidor.

La especificación estándar del protocolo X se encuentra en X Window System Tercera edición, X versión 11, revisión 5 de Robert W. Scheifler y James Getty (Burlington. MA: Digital Press. 1992). Scheifler está ligado al Laboratory for Computer Science de Massachusetts Institute of Tecnology. Gettys lo está al Cambridge Research Laboratory de Digital Equipment Corporation. Scheifler y Gettys son figuras de reconocido prestigio en el diseño y desarrollo del sistema X Window

Los mensajes del protocolo X presentan uno de los cuatro formatos siguientes: formato petición, formato respuesta, formato error o formato suceso.

Peticiones y formato de petición

Una aplicación informa al servidor que requiere un servicio enviando un bloque de datos conocido como Petición (Request). Las peticiones incluyen un código de operación principal de un byte (que identifica el tipo de servicio requerido), un campo longitud de dos bytes, y al menos un byte de datos. El campo longitud define la longitud total de la petición, incluyendo el código de operación y a é1 mismo. El contenido de dicho campo debe ser igual a la mínima longitud necesaria para contener la petición. Se han reservado otros códigos de operación principal para extensiones del protocolo X. Los bytes sin usar en la petición no tienen porque ser necesariamente iguales a cero. El sistema asigna, durante el tiempo de

30


conexión, un número de secuencia consecutivo a cada petición. Este numero identifica la petición asociada con respuestas, errores y sucesos.

Las peticiones normalmente son mensajes de petición de protocolo sin respuesta (one-way protocolo request messages). Estas peticiones no necesitan de una respuesta del sistema. Por ejemplo, cuando queremos crear una ventana, llamamos a una función Xlib como XCreateSimpleWindow. Xlib traduce esta función en un mensaje de protocolo de petición que contiene información apropiada suministrada por la aplicación. Después Xlib almacena el mensaje de petición en una memoria intermedia especial. Mientras la memoria intermedia no esté llena, el mensaje no se envía a la estación de trabajo. Cuando la memoria intermedia se llena, Xlib transmite los mensajes de petición acumulados a dicha estación. Sólo entonces se crea la ventana. La aplicación no detiene el procesamiento, sino que continúa procesando y enviando nuevas peticiones al servidor conforme se requiera. Como la aplicación no espera una respuesta del servidor (estación de trabajo), el tiempo de respuesta es casi independiente de la velocidad de transmisión a través del enlace físico.

Respuestas y formato de respuesta Algunas veces el programa de aplicación no puede continuar sin una respuesta del servidor. Por ejemplo, pueden ser necesarias las dimensiones concretas de un cursor físico. La función Xlib XQueryBestCursor transmite el contenido desde la memoria intermedia (buffer) al servidor, bloquea los procesos adicionales, y transmite dicha petición al servidor. Los procesos continúan sólo cuando el servidor devuelve la información requerida por la aplicación. Tal petición se conoce como mensaje de petición de protocolo de respuesta (round-trip protocol request messages). Estos pueden provocar un considerable retraso, especialmente en sistemas con velocidad de transmisión física relativamente lenta. Como las peticiones de ida y vuelta "paran el trabajo", deben usarse tan sólo cuando sea necesario.

Las respuestas contienen un campo longitud de cuatro bytes seguidos por cero o más bytes que contienen datos adicionales, como se indica en el campo de longitud. Los bytes no usados en la respuesta no tienen porque ser necesariamente iguales a cero. Las respuestas contienen los 16 bits menos significativos del numero de secuencia asociada a la petición.

Errores y formato de error Como cualquier programador sabe, decirle a la computadora lo que queremos hacer es un proceso sujeto a error. No existe garantia de que dada una petición se consigna los resultados deseados. La sintaxis de X Window no es fácil de usar, e incluso cuando es correcta, es posible que el sistema no pueda atender su petición por razones que escapan de nuestro control: por ejemplo, por falta de memoria. La función XCreateSimpleWindow que aparece en el programa "Hola Mundo" del Capítulo 2 puede generar cuatro errores distintos, BadAlloc, BadMatch, BadValue y Badwindow, de entre los errores X que se muestran en la Tabla 3-1.

Entonces, ¿cómo puede el programador determinar el error especifico y la función causante del error? La función de servicio Xlib XSynchronize, habilita o inhabilita la sincronización, es decir, el procesamiento separado de cada función Xlib. Cuando se habilita la sincronización (synchronization). Las peticiones no se almacenan en la memoria intermedia. El sistema acepta una petición, bloquea los procesos, transmite la petición al servidor y espera la respuesta. De este modo, la sincronización facilita al programador la determinación de la función que causó el error, pero ralentiza de forma drástica el rendimiento del sistema.

Los informes de error del protocolo X tienen 32 bytes de longitud. Contienen un código de error de un byte, que identifica el tipo de error producido. Los mensajes de error incluyen el códice de operación mayor y menor de la petición abortada así como los 16 bits menos significativos de su número de

31


secuencia. Recordemos que puede haber un retraso entre el momento en que se realiza la petición y el momento en que se genera el error. Algunos informes de error hacen referencia a objetos no presentes: por ejemplo, a un identificador de ventana erróneo. Los bytes no usados en los mensajes de error no son necesariamente iguales a cero. La estructura de datos de XErrorEvent es como sigue:

Tabla 3-1. Códigos de error X y su descripción.

Código de error X BadAccess RadAlloc BadAtom BadColor Badcursor BadDrawable BadFont BadGC BadlDChoice Badlmplementation BadLength BadMatch BadName BadPiixmap BadRequest BadValue BadWindow

Descripci6n Uno de los diversos errores de acceso Error en la localizaci6n del recurso solicitado El argumento no es un &tomo El argumento no es un mapa de color El argumento no es un cursor El argumento no es un area de dibujo El argumento no es un tipo de letra El argumento no es un contexto grafico ID ya sea en uso o fuera de rango Servidor deficiente Longitud de la petici6n demasiado corta o demasiado larga Argumento no concuerda Color o tipo de letra inexistente El argumento no es un mapa de puntos C6digo de petici6n incorrecto Argumento (tipo entero) fuera de rango El argumento no es una ventana

typedef struct { int type; I* Tipo de suceso *I Display *display; I* Estructura visualizada *I unsigned long serial; I* Número de petici6n fallida * I unsigned char error code; I* C6digo de error de la petici6n fallida *I unsigned char request-code, I* C6digo de operacidn mayor,

XID resourceid; I* Id de recursos *I menor de la petici6n fallida *I

} XErrorEvent

Formato de suceso

El programa “Hola Mundo” del Capítulo 2 muestra la importancia de los sucesos (events) en el sistema X Window. Esencialmente, todas las actividades que afectan al sistema de entrada o salida generan uno o más sucesos. Este capítulo concluye tratando los tipos de sucesos y su procesamiento.

e Los 33 tipos de sucesos tienen el mismo formato:

0 Los sucesos tienen una longitud de 32 bytes.

Los sucesos incluyen un código de tipo de I byte. con el bit más significativo activo si el suceso ha sido generado por una petición SendEvent asociada a otra aplicación.

Cada suceso, excepto el suceso KeyMapNotify genera un formato de mensaje que contiene los 16 bits menos significativos del número de secuencia dei suceso. Este número de secuencia se corresponde con la ultima petición emitida por el cliente que comienza a ejecutarse en el servidor cuando el suceso ocurre.

Los bytes no usados del mensaje suceso no son necesariamente iguales a cero.

32


Archivos de cabecera

Escribir y depurar aplicaciones en el sistema X Window es una tarea dificil. Xlib proporciona numerosos archivos de cabecera estándar que contienen valores específicos del sistema. Si prestamos gran atención a los convenios de nomenclatura y codificación reducirá el esfuerzo de programación y obtendremos programas más portables y fáciles de mantener.

Archivos de cabecera estándar

Los siguientes archivos son parte del sistema estándar X Window (algunos de los detalles que siguen son específicos de la Versión 11.5).

<XI I/Xlib. h> Este es el archivo de cabecera principal para Xlib. Colocando este archivo al principio de los programas incluimos la mayoría de las constantes simbólicas, tipos de datos, y declaraciones de estructuras de datos necesarias para Xlib. El archivo <X11 / Xlib.h> de la actualización 5 incluye el símbolo para el preprocesador XlibSpecifcationRelease, cuyo valor es 5. Las ediciones anteriores de Xlib no incluían este símbolo.

Nota. Los < > que encierran al archivo cabecera le indican al sistema que busque el archivo en la biblioteca dei sistema antes que en otra parte.

<XI l/X. h> En este archivo se declaran los tipos y constantes del protocolo X que pueden ser usados por las aplicaciones. Se incluye automáticamente desde <Xll/Xlib.h>, de manera que el código de las aplicaciones nunca necesitará referenciarlo directamente.

<XI I/Xcms. h> Este archivo contiene los símbolos para muchas de las facilidades de gestión de colores. Todas las funciones. tipos, y símbolos con el prefijo “Xcms”, además de las macros de conversión de colores de contextos, se declaran en este archivo. Antes de incluir este archivo debemos incluir < XI1 /Xlib.h >.

<XIl/Xutil.h > En él se declaran varias funciones. tipos y símbolos que se usan para la comunicación entre clientes y utilidades de aplicación. Debemos incluir <Xll/Xlib.h> antes de incluir este archivo.

<XI I/Xresource. h> En este archivo se declaran todas las funciones, tipos y símbolos para las utilidades de gestión de recursos. Debemos incluir <Xll/Xlih.h> antes de incluir este archivo.

<X1 l/Xetom.h> En él se declaran todos los átomos predefinidos, que son símbolos con el prefijo “m-’’. <XI I/cursortont. h> En este archivo se declaran todos los símbolos de cursor para el tipo de letra estándar del cursor. Todos los símbolos de cursor tienen el prefijo “XC-’’.

<XII/keysymdejh> Con este archivo se declaran todos los valores KeySym estándar, que son símbolos con el prefijo “XK-”. Estos símbolos se disponen en grupos y un símbolo para el preprocesador controla la inclusión de cada grupo. El símbolo para el preprocesador debe ser definido antes de la inclusión del archivo para obtener los valores asociados. Los símbolos para el preprocesador son XK-MISCELLANY, XK-LATINI, XI-LATINZ, XK-LATIN3, XK-LATIN4, XK-KATAKANA, XK-ARABIC, XK-CYRILLIC, XI-GREEK. XI-TECHNICAL. XK-SPECIAL, XKPUBLISHING, XK-APL y XK-HEBREW.

<X1 Ikeysym. h> En éI se definen los símbolos para el preprocesador XK-MISCELLANY, XK-LATINI, XK-LATIN2, XK-LATIN3, XK-LATIN4 y XK-GREEK, y después incluye <Xll/keysymdef.h>.

33


<XII/Xlibint.h> -En este archivo se declaran todas Las funcionas, tipos y símbolos usados en las extensiones del sistema X Window estándar. Este archivo incluye automáticamente <XlVXlib.h>.

<XI I/Xproto. h> Con este archivo se declaren tipas y símbolos del protocolo X básico con el fin de poder usarlos en la implementación de extensiones. Se incluye automáticamente desde < X1VXlibint.h >, por lo que las aplicaciones y el texto de las extensiones nunca necesitarán referenciar este archivo directamente.

<XII/Xprotostr.h> Con este archivo se declaran tipos y símbolos del protocolo X básico para poder usarlos en la implementación de extensiones. Se incluyen automáticamente desde <Xll,Xproto.h>, así las aplicaciones y el texto de las extensiones nunca necesitarán referencia a este archivo directamente.

<X1 I/XlO.h> En este archivo se declaran todas las funciones, tipos y símbolos que se usan para la compatibilidad con las funciones X10.

Nomenclatura Nib y convenios para los argumentos

Aproximadamente 300 funciones Xlib interaccionan con el protocolo X. Utilizar funciones Xlib es similar a programar en lenguaje ensamblador. Los siguientes convenios estándar hacen más fácil la comprensión y utilización de estas funciones.

Xlib utiliza tipos mixtos para los símbolos externos (aquellos no definidos en un archivo de cabecera Xlib). Las variables aparecen en minúscula y las macros en mayúscula, según el convenio de programación del lenguaje C estándar.

Las funciones Xlib siempre comienzan con una letra mayúscula X.

Todos los nombres de funciones y símbolos comienzan con una letra mayúscula.

Todas las estructuras de datos visibles por el usuario y objetos a los que los usuarios pueden acceder mediante una estructura puntero comienzan con una letra mayúscula X.

Las macros y otros símbolos no comienzan con una mayúscula. Todas las letras de las macros se ponen en mayúscula para distinguirlas de otros símbolos de usuario.

Todos los elementos o variables dentro de una estructura de datos se escriben en minúscula. La línea de subrayado (J se utiliza para crear palabras compuestas reservadas para el uso de Xlib. El usuario no puede hacer uso de tales palabras excepto las especificas de Xlib.

Cualquier referencia a un elemento de visualización (display) debe ser el primer argumento de una función Xlib.

Todas las referencias a otros recursos aparecen inmediatamente después del argumento display en la lista de argumentos.

Cuando un contexto gráfico coincide con otro tipo de recursos (tales como una ventana o un mapa de puntos), debe aparecer en la lista de argumentos después de los otros recursos. Las ventanas y mapas de puntos, conocidos como áreas de dibujo, se listan antes de todos los otros recursos. Esto se verá más tarde en este capítulo.

Los argumentos fuente siempre preceden a los argumentos destino en la lista de argumentos.

34

Conceptos básicos y terminologia

El argumento x siempre precede al argumento y en la lista de argumentos.

El argumento width (anchura) siempre precede al argumento height (altura) en la lista de argumentos.

Cuando los argumentos x, y. height y width aparecen juntos. Los argumentos x e y preceden a los argumentos width y height.

Cuando un grupo de bits conocidos como máscara (mask) especifica los elementos que van a ser seleccionados de una estructura de datos que la acompaña, la máscara siempre precede al puntero de la estructura en la lista de argumentos.

Recursos Los recursos son objetos almacenados en el servidor X. Incluyen ventanas, contextos gráficos, tipos de letra, cursores, mapas de colores y mapas de puntos. (En el Capítulo 5 "Herramientas, conceptos y técnicas" se presenta el concepto relacionado de recursos de herramienta.) El uso correcto de los recursos reduce tanto el esfuerzo de codificación como el volumen de datos transferidos entre el cliente y el servidor.

Antes de examinar individualmente cada tipo de recurso, podemos ver sus características comunes:

0 Los recursos se crean mediante una petición simple de una aplicación cliente. Xlib selecciona un identificador de recurso en consonancia con las especificaciones proporcionadas por la estación de trabajo cuando se establece la conexión. A continuación Xlib informa a la aplicación del identificador del recurso.

Los recursos son controlados por la aplicación pero están ubicados en la estación del servidor. Como la información sobre el recurso está ya en la estación de trabajo no necesita ser transferida con cada operación.

Todas las aplicaciones que se ejecutan sobre una misma estación de trabajo pueden compartir un recurso proporcionando su número de referencia. La compartición de los recursos puede ocasionar problemas: cualquier aplicación que acceda a un recurso compartido puede modificarlo o borrarlo. Se pueden proteger los recursos privados declarando los identificadores de los recursos localmente.

Los recursos no pueden ser compartidos entre estaciones de trabajo. Un recurso creado sobre una estación A no es accesible por otra estación B.

Los recursos no se pueden almacenar en las estaciones de trabajo entre sesiones. Sin embargo, es fácil crearlos y destruirlos. Una aplicación tipica usa muchas ventanas, contextos gráficos, tipos de letra, y otros recursos.

Ventanas

Las ventanas son en general áreas rectangulares de visualización que aparecen en el monitor Son el recurso más importante del servidor. Siempre que una aplicación X dibuja un gráfico o presenta un texto, debe especificar la ventana de salida que utiliza. Es más, tanto el ratón como el teclado acceden al sistema a través de una ventana. Materialmente docenas de funciones Xlib controlan la creación, localización, manipulación y destrucción de ventanas.

35

Conceptos basicos y terminología

El programa "Hola Mundo" del Capítulo 2 emplea la función XCreateSimpleWindow. A continuación se muestra la más potente función de Xlib, XCreateWindow:

Window XCreateWindow (display, parent, x, y, width, height, border-width, depth, class, visual, valuemask. attributes)

Display *display; Window Parent; int x, y;

unsigued int width, height; unsigned int boder-width;

unsigned int depth;

unsigned int class;

Visual "visual; unsigned long valuemask; XSetWindowAttributes

I* Estructura de viaualisaci6n *I I* Ventana padre *I I* Coordenadas de la esquina superior izquierda de la ventana *I I* Dimensiones de la ventana *I I* Anchura del horde en puntos (pixels) *I I* Profundidad de la ventana en puntos (pixels) -1 I* Inputoutput (Entradasalida), Inputonly (SbloEntrada), CopyFromParent (Copia del Padre) *I I* Tipo de viuualizaci6n "1 I* Mascara para atributos de ventana -1

*attributtes I* Atributos de la ventana *I

Window window; I* Devuelve el Identificador (ID) de la ventana creada *I

Igual que la función XCreateSimpleWindow, la función XCreateWindow crea una ventana que no se visualiza en pantalla. En el Capítulo 4, "Ventanas y técnicas de trabajo con ventanas', se examinan las ventanas en detalle.

Contextos gráficos

Un contexto grdfico (graphics context, abreviado GC), es una estructura de datos que gestiona las características de los gráficos, incluyendo el tipo de línea y su anchura, colores de fondo y primer plano, y patrones de relleno. Toda petición para generar una salida gráfica debe hacer referencia a un contexto gráfico. A diferencia de otros recursos, las aplicaciones no podrán compartir contextos gráficos.

Por ejemplo, la función XSetFont, establece el tipo de letra de un contexto gráfico. La sintaxis de XSetFont es

XSetFont (display, gc, font) Display *display; GC gc; Font font;

donde display es la estructura de visualización, gc es el contexto gráfico, y font es el tipo de letra.

La función XSetFont puede generar los siguientes errores:

BadAlloc, cuando el servidor no puede disponer del recurso requerido.

36


~

BadFont, cuando el valor del argumento del tipo de letra no se corresponde con un tipo existente.

BadGC, cuando el valor de un argumento de contexto gráfico, no se corresponde con el nombre de un contexto gráfico definido.

En el Capitulo 6, "Textos", y en el Capítulo 10 "Color y gráficos" se tratan con mayor detalle 10s contextos gráficos.

Tipos de letra (Fonts)

Un tipo de letra Cfont) describe el tamaño y forma de cada carácter dentro de un conjunto homogéneo de caracteres. X Window proporciona un gran número de tipos de letra con nombres estándar, tales como

Adobe-Courier-Bold-R-Normal-25- 180-100-1 00-"150

Los números hacen referencia a los diferentes tamaños del tipo de letra.

X Window permite el uso de tipos de letra para lenguas extranjeras. La siguiente función Xlib, XCreateFontSet (Revisión 5), genera un juego de caracteres gráficos internacional denominado XFontSet:

XFonSet XCreateFontSet (display, base-font-name-list, missing chrasert-list-return, missing-charset-count-return, def-strlngreturn)

Display *display; I* Estructura de visualizaci6n *I char *base-font-name-list; I* Nombres de tipos de letra base *I char *missingcharset-list-return; I* Conjunto de caracteres no definido *I int *missingcharset-count-return; /* Nhmero de caracteres no definido *I char **def-stringreturn;: I* Devuelve la cadena de caracteres no definido *I

El tipo de letra Bold Courier es facilitado por una compañía conocida como Adobe. Es un tipo de letra latina (no cursiva), de anchura normal y monoespacido; todos los caracteres tienen la misma anchura. En el Capítulo 6, 'Textos", se describen los convenios de nomenclatura de los tipos de letra y su uso en la creación y modificación de textos de salida.

Cursores

El recurso cursor describe el tamaño, color y forma del cursor de pantalla asociado al ratón. Cuando el ratón u otro dispositivo apuntador se mueve. el cursor se mueve. Una forma de crear un cursor es seleccionando un carácter Único de entre un conjunto especial de cursores. La siguiente función Xlib selecciona el cursor de mayor tamaño que puede aparecer sobre la unidad de visualización elegida.

Status XQuery8etCursor (display,d, width, height, width-return, height-return)

Display *display; I* Estructura de visualizaci6n *I Drawble d; I* La pantalla que indica un Area de dibujo *I unsigned int width, height; /* Dimensiones del cursor solicitado *I unsigned int *width-return, *height-return; I* Número de caracteres no definido */

Conceptos basicos y terminología

La función XQueryBestCursor genera un mensaje de protocolo con repuesta (round-trip protocol message), y por consiguiente puede acarrear un considerable tiempo de espera. En el Capítulo 8 "El ratón", se discute con mayor detalle el cursor, junto con el ratón.

Mapas de colores (Colormaps)

El procesamiento de los colores es complicado. Unos colores que pueden resultar atractivos en una estación de trabajo pueden no serlo sobre otra estación. El recurso X mapa de colores ayuda a los programadores a gestionar los cientos de colores disponibles en los sistemas X Window. Un mapa de cozores (colormap) es un mapa que asocia un valor en cada punto (pixel) con un color. La función Xlib. XlnstallColorMap, activa un mapa de colores para una pantalla concreta. Al asignar un mapa de colores se asegura que todas las ventanas presentan sobre la pantalla colores adecuados. Si no se ha activado un mapa de colores en una pantalla. puede que sus ventanas no presenten colores adecuados.

XInstallColorMap (display, colormap) Display *display; I* Estructura de visualizaci6n * I Colormap colormap; I* Mapa de colores *I

Mapas de puntos (Pixmaps)

Un mapa de puntos es un bloque de memoria, asociado al servidor X, que puede ser usado para dibujar. Recordemos que las ventanas (windows) y mapas de puntos (pixmaps) se llaman áreas de dibujo (drawable). A diferencia de las ventanas, los objetos dibujados en los mapas de puntos no aparecen sobre la pantalla. Para verlos se debe copiar el contenido del mapa de puntos en una ventana visible. Los mapas de puntos a menudo almacenan patrones especiales para cursores y fondos de ventanas. Un mapa de puntos cuyos puntos (pixels) son representados cada uno por un único bit se llama un mapa de bits (bitmap).

La función XCreatePixmap crea un mapa de puntos. Si la función se ejecuta con éxito, el programador podrá disponer del identificador de recurso del mapa de puntos.

Pixmap XCreatePixmap (display,d, width, height, depth)

Display *display; Drawble d; unsigned int width, height; unsigned int depth;

I* Estructura de visualizaci6n *I /* Pantalla sobre la cual se crea el mapa de puntos *I I* Dimensiones del mapa de puntos *I I* Profundidad del mapa de puntos *I

En el capítulo 9, "Mapas de puntos, mapas de bits e imágenes" se tratan con mayor detalle 10s mapas de puntos y los mapas de bits

Sucesos

El procesamiento de sucesos es el objetivo central del sistema X Window. Cualquier actividad que afecte a las entradas o salidas, además de otras muchas actividades, genera uno o más sucesos. Una aplicación activa está constantemente produciendo sucesos, sin ningún orden particular. Por ejemplo, un usuario puede mover el ratón a través de diversas ventanas y con una doble pulsación del botón seleccionar un menú determinado, provocando la aparición de un menú desplegable sobre la pantalla. Este rápido escenario puede generar literalmente docenas de sucesos de diferentes tipos. La aplicación puede permitirse elegir sólo algunos tipos de sucesos, pero no puede ignorarlos todos. Por ejemplo, una

38


aplicación podría advertir cuando se pulsa el botón, y no cuando se libera; pero una aplicación que no reconoce sucesos relacionados con el ratón no podría usarlo.

Tipos de sucesos

El sistema X Window proporciona 33 tipos distintos de sucesos, que pueden ser clasificados en diversas categorías: sucesos de teclado (keyboard events), sucesos de puntero (pointer events), sucesos de cruce de ventanas (windowcrossing events), sucesos de focalización (input focas events), sucesos de notificación del estado de asignación de las teclas (keymap state notification events), sucesos de exposición (expuse events), sucesos de control de estructura (structure control events), sucesos de notificación del estado de la ventana (window state notification events), sucesos de notificación dei estado de los mapas de colores (colormap state notification events), y sucesos de comunicación entre clientes (client communication events). En todos los casos los sucesos se asocian con una estructura de datos definida en el archivo de cabecera < X11 I X1ib.h >. Aquí vamos a introducir cada categoría de sucesos. Los tipos de sucesos individuales se trataran en capítulos posteriores.

Sucesos de teclado (keyboard events)

Los sucesos de teclado (ketboard erents) indican la pulsación o liberación de una tecla. Estos dos sucesos se denominan Keypress (tecla-pulsada) y KeyRelease (tecla-liberada) respectivamente, y están asociados con la estructura de datos XKeyEvent. Esta estructura de datos contiene 15 campos. que incluyen el tipo de suceso. el número de serie de la última petición procesada, la identificación del monitor (estructura de visualización) y ventana que registra el suceso, el tiempo en que tiene lugar el suceso, las coordenadas del puntero a la ventana del suceso, y el código correspondiente a la tecla asociada con el suceso de teclado.

Sucesos de puntero (pointer events)

Los sucesos de puntero (pounter events) están asociados con un puntero, normalmente el puntero del ratón. Los tres tipos de sucesos de puntero son ButtonPress (botón-pulsado), ButtonRelease (botón-liberado), y MotionNotifv (notificación de movimiento). Los dos primeros sucesos de puntero están asociados con la estructura de datos XButtonEvent que contiene 15 campos. Esta estructura de datos puede ser referenciada como XButtonPressedEvent y XButtonReleaseEvent respectivamente. Los sucesos de notificación de movimiento están asociados con la estructura de datos XMotionEvent, que también contiene 15 campos 14 de los cuales son los mismos que para los dos sucesos anteriores. Entre los campos de estas estructuras de datos se encuentran el tipo de suceso. el número de serie de la última petición procesada, la identificación del monitor y ventana que registran el suceso, el tiempo en que tiene lugar el suceso v las coordenadas del puntero asociado a la ventana del suceso. Los sucesos ButtonPress y ButtonRelease contienen una referencia al botón pulsado o liberado (números dei I al 5). Los sucesos MotionNotify también contienen un campo asociado con las características de movimiento del puntero.

Sucesos de cruce de ventanas (window-crossing events)

Los sucesos EnterNotity (notificación de entrada) y LeaveNotify (notificación de salida) indican cuando el puntero del ratón entra o abandona una ventana seleccionada. Se encuentran asociados a la estructura de datos XCrossingEvent. Esta estructura contiene 17 campos, muchos de los cuates son los mismos o similares a los de los sucesos de puntero.

Sucesos de focalización de la entrada (input facas events)

La focalización del teclado (keyboard focus), también llamada focalización de la entrada (input focus), indica la ventana asociada con el teclado. Los usuarios cambian la focalización del teclado moviendo el


__ ~ ~ _ _ ~

ratón dentro de la ventana deseada. (Dependiendo de las especificaciones del sistema, puede que tengan que pulsar el botón del ratón para confirmar la selección.) Al cambiar el enfoque se generan los sucesos FocusIn (Enfocar) y FocusOut (Desenfocar), el primero para indicar la ventana receptora del input focas, y é1 segundo para especificar la ventana que abandona el input focas. Estos sucesos están asociados con la estructura de datos XFocusChangeEvent que contiene siete campos, que incluyen el tipo de suceso, el número de serie de la última petición procesada y la identificación del monitor y ventana que registran el suceso.

Sucesos de notificación del estado de asignación de las teclas (kqmap state notification events)

El suceso KeymapNotify (notifcaciórl de asignación de las teclas) es el Único tipo de suceso de esta categoría. Este suceso fija el estado de todas las teclas al darse un suceso FocusIn o EnterNotify. Recordemos del programa "Hola Mundo" del Capítulo 2, que este tipo de sucesos debería seleccionarse siempre. El suceso KeymapNotify está asociado con la estructura de datos XKeymapEvent y contiene seis campos, que incluyen el tipo de suceso, el número de serie de la última petición procesada, y la identificación del monitor y ventana que registran el suceso. También incluye una referencia al conjunto de códigos de teclas activo.

Sucesos de exposición (exposure events)

Los sucesos exposure expresan la interferencia entre ventanas múltiples sobre una misma pantalla. Las pantallas contienen normalmente más de una ventana, el sistema X Window no obliga a la yuxtaposición completa de las ventanas. Al contrario, las ventanas pueden superponerse, lo que conlleva un problema que debe solucionarse, cuando una ventana A cubre toda o parte de una ventana B, el contenido relevante de la ventana B desaparece de la pantalla. La aplicación debe poder restaurar este contenido cuando la ventana B deje de estar cubierta. o usando términos más técnicos, cuando se exponga. Cuando parte de una ventana deba ser dibujada de nuevo, el servidor genera un suceso Expose (Exposición) para cada área afectada. En general, las aplicaciones esperan a un suceso Expose antes de dibujar sobre una ventana. Tales sucesos señalan que la ventana está preparada para recibir un contenido,

Los otros dos tipos de sucesos de exposición son GraphicsExpose y NoExpose. Un suceso GraphicsExpose indica que un intento para copiar desde un mapa de puntos a una ventana no se llevo a cabo con éxito porque al menos una parte de la ventana destino estaba oculta. Un suceso NoExpose indica que la copia se completo con éxito. Los tres sucesos de exposición están asociados con la estructura de datos XExposeEvent que contiene nueve campos. que incluyen el tipo de suceso el número de serie de la última petición procesada. el origen y dimensión del área expuesta, y el número de sucesos de exposición adicionales a procesar.

Sucesos de control de estructura (Structure Control Events)

Hay cuatro tipos de sucesos de control de estructura: CirculateRequest (petición circular), ConfigureRequest (petición de configuración), MapRequest (petición de visualización) y ResizeRequest (petición de redimensionamiento). Estos sucesos son usualmente manipulados por el gestor de ventanas.

Suceso CirculateRequest (petición circular)

El suceso CirculateRequest intenta subir o bajar una ventana en la pila de ventanas. Está asociado con la estructura de datos XCirculateRequestEvent, que contiene siete campos, que incluyen el tipo de suceso, el número de serie de la última petición procesada, la conexión de visualización, la identificación de la ventana solicitada, la identificación de la ventana padre de la solicitada, y una identificación de si se sube o se baja la ventana en el orden de la pila.

40


Suceso ConfigureRequest (petición de configuración)

El suceso ConfigureRequest intenta cambiar el tamaño de una ventana, la posición, el borde, o el orden en la pila. Se generan cuando otro cliente emite una petición de protocolo ConfigureWindow (configuración de ventana) sobre una ventana hija. Los sucesos ConfigureRequest están asociados con la estructura de datos XConfigurateRequestEvent, que contiene 14 campos, que incluyen el tipo de suceso, el número se serie de la última petición procesada, la conexión de visualización, la identificación de la ventana solicitada, la identificación de la ventana padre de la solicitada. y las dimensiones de la ventana.

Suceso MapRequest (petición de visualización)

El suceso MapRequest indica que un cliente diferente desea visualizar una ventana. Está asociado con la estructura de datos XMapRequestEvent, que contiene seis campos, que incluyen el tipo de suceso, el numero de serie de la ultima petición procesada, la conexión de visualización, la identificación de la ventana solicitada y la identificación de la ventana padre de la solicitada.

Suceso ResizeRequest (petición de redimensionamiento)

El suceso ResizeRequest indica que un cliente distinto desea redimensionar una ventana. Está asociado con la estructura de datos XResizeRequestEvent, que contiene siete campos, que incluyen el tipo de suceso, el número de serie de la última petición procesada, la conexión de visualización, la identificación, la anchara, y la altura de la ventana solicitada.

Sucesos de notificación del estado de la ventana (Window State Notification Events)

El servidor genera un suceso de notificación del estado de la ventana siempre que una ventana se mueva, cambie de tamaño o cambie su lugar en el orden en la pila. Por orden alfabético, estos sucesos son: CirculateNotify (notificación circular), ConfigureNotify (notificación de configuración), CreateNotifv (notificación de creación), DestroyNotify (notificación de destrucción), GravityNotify (notificación de atracción), MapNotify (notificación de visualización), MappingNotify (notificación de asignación), ReparentNotify (notificación de nuevos padres), UnmapNotify (notificación de no visualización) y VisibilityNotify (notificación de visibilidad).

Suceso CirculateNotih (notificación circular)

Los sucesos CirculateNotify informan a los clientes interesados cuando una ventana cambia su posición en la pila. Estos sucesos están asociados con la estructura de datos, XCirculateEvent, que contiene siete campos, incluyendo el tipo de suceso, el número de serie de la última petición procesada, la conexión de visualización, la identificación de la ventana solicitada, y si se coloca la ventana al comienzo o en el fondo de la pila.

Suceso ConfigureNotl> (notificación de configuración)

Los sucesos ConfigureNotify dorman a los clientes interesados de los cambios en una ventana, incluyendo su tamaño, posición, borde y orden en la pila. Estos sucesos están asociados con la estructura de datos, XConfigureEvent, que contiene trece campos, incluyendo el tipo de suceso, el número de serie de la última petición procesada, la conexión de visualización, la identificación, las dimensiones, y la anchura del borde de la ventana afectada.

41


Suceso CreateNotiJj, (notificación de creación)

Los sucesos CreateNotify informan a los clientes interesados que una ventana ha sido creada. Estos sucesos están asociados con la estructura de datos, XCreateEvent, que contiene doce campos, incluyendo el tipo de suceso, el número de serie de la última petición procesada, la conexión de visualización, la identificación y las dimensiones de la ventana creada, la identificación de sus padres, y la anchura del borde.

Suceso DestroyNotiJj, (notificación de destrucción)

Los sucesos DestroyNotify informan a los clientes interesados cuando se destruye una ventana. Estos sucesos están asociados con la estructura de datos, XDestroyEvent, que contiene seis campos, incluyendo él tipo de suceso, el numero de serie de la última petición procesada, la conexión de visualización, y la identificación de la ventana destruida.

Suceso GravityNotiJj, (notificación de atracción)

Los sucesos GravityNotify informan a los clientes interesados de que una ventana se desplaza a causa de que su ventana padre cambia de tamaño. Estos sucesos están asociados con la estructura de datos, XGravityEvent, que contiene ocho campos, incluyendo el tipo de suceso, el número de serie de la última petición procesada, la conexión de visualización, la identificación de la ventana que se desplaza o la de su padre, y las coordenadas de la ventana hija con respecto a las de su padre.

Suceso MapNotiJj, (notificación de visualización)

Los sucesos MapNotify informan a los clientes interesados de que el estado de una ventana cambia de no visualizada a visualizada. Estos sucesos están asociados con la estructura de datos, XMapEvent, que contiene siete campos, incluyendo el tipo de suceso, el número de serie de la última petición procesada, la conexión de visualización, y la identificación de la ventana visualizada o la de su padre.

Suceso MappingNotifi (notificación de asignación)

Los sucesos MappingNotify informan a todos los clientes cuando una aplicación de un cliente llama a una de las tres funciones Xlib siguientes: XSetModifierMapping, que indica los códigos de las teclas que han a ser usadas como modificadores; XChangeKeyboardMapping y XSetPointerMapping. Los clientes no pueden bloquear la transmisión de los sucesos MappingNotify. Estos sucesos están asociados con la estructura de datos, XMappingEvent, que contiene ocho campos, incluyendo el tipo de suceso, el número de serie de la última petición procesada, la conexión de visualización, una indicación de cuál de las tres funciones Xlib fue utilizada, y el número de los códigos de tecla modificados.

Suceso ReparentNotlfi (notificación de nuevos padres)

Los sucesos ReparentNotiiy informan a los clientes interesados cuando una ventana cambia de padre. Estos sucesos están asociados con la estructura de datos, XReparentEvent, que contiene diez campos, incluyendo el tipo de suceso, el número de serie de la última petición procesada, la conexión de visualización, la identificación de la ventana que ha cambiado de padre y sus coordenadas relativas a la nueva ventana padre, así como el identificador de la nueva ventana padre.

42


Suceso UnmapNotiJjl (notificación de no visualización)

Los sucesos UnmapNotify informan a los clientes interesados cuando el estado de una ventana cambia de visualizada a no visualizada. Estos sucesos están asociados con la estructura de datos, XUnmapEvent, que contiene siete campos, que incluyen el tipo de suceso, el número de serie de la última petición procesada la conexión de visualización, y la identificación de la ventana que estaba visualizada o la de su padre.

Suceso VisibilityNotiJjl (notcjicación de visibilidad)

Los sucesos VisibilitvNotify informan a los clientes interesados cuando ocurre un cambio en la visibilidad de una ventana dada. Estos sucesos están asociados con la estructura de datos, XVisibilityEvent, que contiene seis campos, que incluyen el tipo de suceso, el número de serie de la última petición procesada, la conexión de visualización, la identificación de la ventana cuya visibilidad cambia, y una indicación del cambio en la visibilidad.

Suceso de notificación del estado del mapa de colores (Colormap State Notification Event)

El Único suceso de notlficación del estado del mapa de colores es el suceso ColormapNotify, que informa a los clientes interesados cuando cambia el mapa de asignación de colores y cuando se instala o desinstala dicho mapa. Estos sucesos están asociados con la estructura de datos, XColormapEvent, que contiene ocho campos, incluyendo el tipo de suceso, el número de serie de la última petición procesada, la conexión de visualización, la identificación de la ventana afectada, el mapa de colores, y si el mapa de colores h e instalado o desinstalado.

Sucesos de comunicación entre clientes (Client Communication Events)

Los sucesos de comunicación entre clientes permiten a las aplicaciones comunicarse entre sí. Tal comunicación no es directa, sino a través de la estación de trabajo. Existen cinco sucesos de comunicación entre clientes: ClientMessage (mensaje de cliente), PropertyNotify (notificación de propiedad), Selectionclear (borrado de selección), SelectionNotify (notificación de selección), y SelectionRequest (petición de selección).

Suceso ClientMessage (mensaje de cliente)

Los sucesos ClientMessage ocurren cuando un cliente llama a la función Xlib XSendEvent para enviar un suceso a otro cliente. Esta función debe ser usada con precaución. Estos sucesos están asociados con l a estructura de datos, XClientMessageEvent, que contiene ocho campos, uno de los cuales es unión de tres campos. Entre los campos de esta estructura está el tipo de suceso, el número de serie de la última petición procesada, la conexión de visualización, la identificación de la ventana .receptora, y el formato del suceso enviado.

Suceso PropertyNotiJjl (notificación de propiedad)

Una propiedad es una colección arbitraria de datos usados en la comunicación entre clientes. Los sucesos PropertyNotify informan a los clientes interesados de los cambios de propiedad de una ventana especifica. Estos sucesos están asociados con la estructura de datos, XPropertyEvent, que contiene ocho campos, incluyendo el tipo de suceso, el número de serie de la última petición procesada, la conexión de visualización, la identificación de la ventana afectada, el tiempo en el que tuvo lugar el cambio de la propiedad, e indicación de si la propiedad fue modificada o borrada.

43


Suceso Selection Clear (borrado de selección)

Una selección es un tipo especial de memoria intermedia usada para trasladar datos de una aplicación a otra. Una selección es una forma de comunicación entre clientes. Los datos seleccionados se pasan de una aplicación a otra y se almacenan en una propiedad. Los sucesos SelectionClear ocurren cuando un cliente pierde la posesión de una selección. Estos sucesos están asociados con la estructura de datos, XSelectionClearEvent, que contiene siete campos, incluyendo el tipo de suceso, el número de serie de la Última petición procesada, la conexión de visualización, la identificación de la ventana afectada y el momento del último cambio registrado para la selección.

Suceso SelectionRequest (petición de selección)

Los sucesos SelectionRequest informan a los propietarios de una selección que otra aplicación ha solicitado la conversión de esta selección a otro tipo de datos diferente. Estos sucesos están asociados con la estructura de datos XSelectionRequestEvent, que contiene diez campos, incluyendo el tipo de suceso, el número de serie de la última petición procesada, la conexión de visualización, la identificación del propietario y la identificación de las ventanas seleccionadoras.

Suceso SelectionNotiJjr (notificación de selección)

Los sucesos SelectionNotify son generados por el servidor como respuesta a la petición de protocolo ConvertSelection (conversión de la selección) cuando la selección no tiene propietario. Estos sucesos están asociados con la estructura de datos, XSelectionEvent, que contiene nueve campos, incluyendo el tipo de suceso, el número de serie de la última petición procesada, la conexión de visualización y la identificación de la ventana solicitante.

Resumen de categorías y tipos de sucesos La siguiente tabla resume los tipos de sucesos asociados con cada categoría de sucesos.

Categoría de sucesos Sucesos de teclado

Sucesos de puntero Sucesos de cruce de ventanas Sucesos de focalización de la entrada Sucesos de notificación del estado de asignación de las teclas Sucesos de exposición Sucesos de control de estructura Sucesos de notificación del estado de la ventana

Sucesos de notificación del estado del mapa de colores Sucesos de comunicación entre clientes

Tipo de suceso Keypress, KeyRelease Buttonpress, ButtonRelease, MotionNotify EnterNotify, LeaveNotify

FocusIn, FocusOut

KeymapNotify

Expose, GraphicsExpose, NoExpose CirculateRequest, ConfigureRequest, MapRequest, ResizeRequest CirculateNorify, ConfigureNotify, CreateNotify, DestroyNotify, GravityNotify, MapNotify, MappingNotify, ReparentNotify, UnmapNotify, VisibilityNotity ColormapNotify

ClientMessage, PropenyNotify, SelectionClear, SelectionNotify, SelectionRequest

44


Estructuras de sucesos

Cada uno de los 33 tipos de sucesos X Window está asociado con una estructura de datos declarada en la biblioteca de cabecera < XI1 I X1ib.h >.. Los componentes exactos de cada estructura de datos dependen del suceso en cuestión. Por ejemplo, algunos sucesos requieren la localización del puntero del ratón, mientras que otros no Estas estructuras de sucesos difieren de un tipo de suceso a otro, pero todos incluyen ciertos componentes. Elementos comunes de los sucesos

Todas las estructuras de sucesos contienen los siguientes cinco campos:

typedef struct { int type; unsigned long serial; /* Número de la ultima petici6n procesada */ Boo1 send-event; /* TRUE si el suceso es emitido por una *I

Display *display; /* Monitor en el que se lee el suceso */ Window window;

/* petici6n SendEvent (Enviar Suceso) */

} XAnyEvent;

El tipo es un nombre que identifica de manera unívoca al suceso, como, por ejemplo, Expose. Los 16 bits menos significativos del número de serie generado por la petición de protocolo han sido expendidos a un valor de 32 bits almacenado en la estructura de datos del suceso. El campo send event se pone a VERDADERO si el suceso fue enviado por una petición de enviar-suceso asociada con otra aplicación; en caso contrario, se pone a FALSO. El campo display contiene un puntero a la conexión de visualización que registra el suceso. El campo ventana (window) se asocia con la ventana pertinente, de acuerdo con el tipo de suceso.

Estructura XEvent

La estructura de datos XEvent es una colección de estructuras de datos individuales declaradas para cada tipo de suceso. Se puede acceder a la estructura de datos individual de un suceso mediante la estructura de datos XEvent como se muestra aquí:

typedef union-XEvent { lnt type; XAnyEvent xany; XXeyEvent xkey; XButtonEvent xbutton; XMotionEvent xmotion; XCrossingEvent xcrossing; XFocusChangeEvent xfocus; XExposeEvent xexpose; XGraphicasExposeEvent xgraphicsexpose; XNoExposeEvent xnoexpose; XvisibilityEvent xvisibility; XcreateWindowEvent xcreatewindow; XDeatroyWindowEvent xdestroywindow; XunmapEvent xunmap; XMapEvent xmap; XMapRequestEvent xmaprequest; XReparentEvent xreparent; XConfigureEvent xconfigure; XgravityEvent xgravity; XReizeRequestEvent xresizerequest; XConfigureRequestEvent xconfígurerequest;

45


XCirculateEvent xcirculate; XCirculateRequestEvent xcirculaterequest; XPropertyEvent xproperty; XSelectionClearEvent xselectionclear; XSelectionRequeatEvent xselectionrequest; XSelectionEvent xselection; XColormapEvent xcolormap; XClientMessageEvent xclient; XMappingEvent xmapping; XErrorEvent xerror; XKeymapEvent xkeymap; long pad [24]; } XEvent;

Máscaras de sucesos

Un servidor activo X Window genera un inmenso número de sucesos, de modo que los programas podrían tener dificultad al tratar todos los sucesos generados. Afortunadamente, muchos sucesos son irrelevantes para una ventana o una aplicación. Como mostrábamos en el programa “Hola Mundo” del Capítulo 2, un programa selecciona los tipos de sucesos de interés para é1 fijando primero los bits de la máscara de suceso (event mask) definida en la biblioteca de cabecera estándar e invocando después la función XSelectlnput. Una máscara de suceso es un grupo de bits en el que cada bit se refiere a un tipo diferente de suceso. Cuando un bit esta a 1, el tipo de suceso asociado se selecciona. En general, cuando un bit esta a O, el tipo de suceso asociado no se selecciona.

En la siguiente tabla se listan las máscaras de suceso y cuándo se aplican.

Máscara de suceso

NoEventMask KeyPressMask KeyReleaseMask ButtonPressMask ButtonReleaseMask EnterWindowMask LeaveWindowMask PointerMotionMask PointerMotionHintMask ButtonlMotionMask Button2MotionMask Button3MotionMask Button4MotionMask ButtonSMotionMask ButtonMotionMask KeymapStateMask ExposureMask VisibilityChangeMask StructureNotifyMask ResizeredirectMask SubstructureredirectMask SubstructureRedirectMask FocusChangeMask PropertychangeMask

Corresponde a

Ningún suceso requerido Teclas pulsadas Teclas liberadas Botón del ratón pulsado Botón del ratón liberado El puntero entra en una ventana El puntero abandona una ventana El puntero cambia de posición Características de movimiento del puntero Movimiento mientras el botón 1 del ratón esta pulsado Movimiento mientras el botón 2 del ratón esta pulsado Movimiento mientras el botón 3 del ratón esta pulsado Movimiento mientras el botón 4 del ratón esta pulsado Movimiento mientras el botón 5 del ratón esta pulsado Movimiento mientras cualquier botón del ratón está pulsado El estado del teclado pasa entradas a la ventana y focalización Todas las exposiciones Todo cambio en visibilidad Todo cambio en la estructura de la ventana Redimensionamiento indirecto de la ventana Notificación de subestructura Peticiones indirectas relativas a subestructura Todo cambio en enfoque de entrada Todo cambio en propiedades

46


~~

ColormapChangeMask Todo cambio en el mapa de colores OwnerGrabButtonMask Se activan automáticamente las capturas cuando owner-events es

VERDADERO

47


Puntos Clave

Protocolo X El servidor y el cliente se comunican vía el protocolo X. Los mensajes del protocolo se clasifican en cuatro tipos: peticiones del cliente al servidor, respuestas del servidor al cliente, mensajes de error cuando la petición no se completó con éxito y mensajes de sucesos que informan al cliente interesado que se llevó a cabo una acción. Cada tipo de mensaje tiene su propio formato.

Peticiones

Una aplicación informa al servidor que requiere un servicio enviando un bloque de datos conocido como petición. Las peticiones son normalmente mensajes unidireccionales. Tales peticiones no necesitan de un sistema de respuesta.

Respuestas

Algunos programas de aplicación no pueden continuar sin una respuesta especifica del servidor. Por ejemplo, la función Xlib XQueryBestCursor transmite el contenido de la memoria intermedia al servidor, bloquea el resto de los procesos, y transmite la petición dada al servidor. Los procesos bloqueados se reanudan sólo cuando el servidor devuelve la información solicitada a la aplicación. Tales peticiones se conocen como mensajes de protocolo de petición de ida y vuelta, Estos pueden conllevar un considerable retraso, especialmente en sistemas con velocidad de transmisión relativamente lenta.

Errores

No existe garantía de que dada una petición se obtenga los resultados deseados (la sintaxis X Window no es fácil de usar). La función de servicio Xlib XSynchronize habilita o inhabilita la sincronización. procesando cada función Xlib por separado. Cuando la sincronización está habilitada, las peticiones no son almacenadas en la memoria intermedia. El sistema acepta una petición, bloquea los procesos, transmite la petición al servidor, y espera una respuesta. El modo de sincronización facilita al programador la determinación de la función que causó el error pero hace caer drásticamente el rendimiento dei sistema.

Formato de suceso

En esencia todos las actividades que afecten al sistema de entrada o salida generan uno o más sucesos. Los 33 tipos de sucesos presentan el mismo formato.

Archivos de cabecera estándar

Los archivos de cabecera estándar facilitan información, por ejemplo los tipos del protocolo X y las constantes utilizadas por las aplicaciones. Los archivos de cabecera específicos a incluir dependen de las necesidades de la aplicación y de la versión y edición del sistema X Window.

48


Nomenclatura N i b y convenios para los argumentos

Las aproximadamente 300 funciones de Xlib se comunican con el protocolo X. Utilizar las funciones Xlib es similar a programar en lenguaje ensamblador. La nomenclatura estándar y los convenios en 10s argumentos facilitan la comprensión y utilización de estas funciones.

Recursos

Los recursos son objetos almacenados en el servidor X, éstos incluyen ventanas, contextos gráficos, tipos de letra, cursores, mapas de colores y mapas de puntos. El uso correcto de los recursos reduce tanto el esfuerzo en la codificación como el volumen de datos transferidos entre el cliente y el servidor. Los recursos se crean mediante peticiones unidireccionales de las aplicaciones cliente. Los recursos son controlados por la aplicación pero se almacenan en la estación de trabajo del servidor.

Ventanas

Las ventanas son generalmente áreas rectangulares de pantalla que aparecen en el monitor. Son los recursos más importantes del servidor. Si una aplicación dibuja un gráfico o visualiza un texto, debe especificar la ventana involucrada en la salida. Tanto el ratón como el teclado tienen la entrada al sistema a través de una ventana.

Contextos gráficos

Los contextos gráficos (GC, Graphics Contexts) son estructuras de datos que gestionan representaciones gráficas, incluyendo los tipos y anchura de las líneas, el color de fondo y de primer plano, y los patrones de relleno. Cada petición que genere una salida gráfica debe hacer referencia a un contexto gráfico. A diferencia de otros recursos, las aplicaciones no podrán compartir contextos gráficos.

Tipos de letra

Un tipo de letra describe el tamaño y la forma de cada carácter dentro de una colección homogénea de caracteres. El sistema X proporciona un gran número de tipos de letra con denominaciones estándar.

Cursores

El recurso cursor describe el tamaño, color, y forma del cursor de pantalla asociado al ratón. Cuando el ratón u otro dispositivo apuntador se mueve, el cursor se mueve. Una forma de crear un cursor es seleccionando un ímico carácter de un juego de cursores especial.

Mapas de colores El procesado de colores es complicado. Los colores que se visualizan adecuadamente sobre una estación de trabajo pueden parecer no tan buenos en otra. El recurso X mapa de colores ayuda a los programadores a gestionar los cientos de colores disponibles en los sistemas X Window. Un mapa de colores es un mapa que asocia un valor de cada punto (pixel) con un color.

49


Mapas de puntos

Un mapa de puntos es un bloque de memoria, asociado con el servidor X, que puede ser usado para dibujar. Las ventanas y mapas de puntos se denominan áreas de dibujo. Al contrario que en las ventanas, los objetos dibujados en un mapa de puntos no aparecen sobre la pantalla. Para verlos, debemos copiar el contenido del mapa de puntos en una ventana visualizable. Los mapas de puntos a menudo almacenan dibujos especiales para cursores y fondos para las ventanas. Un mapa de puntos cuyos puntos (pixels) vienen representados cada uno por un bit se denomina mapa de bits.

Sucesos

Procesar sucesos es el interés central del sistema X Window. Cada actividad que afecta a la entrada O

salida. v otras muchas, genera uno o más sucesos. Una aplicación activa está constantemente produciendo sucesos sin ningún orden particular.

Tipos de sucesos

El sistema X Window proporciona 33 tipos de sucesos diferentes, que pueden ser clasificados en distintas categorías sucesos de teclado (keyboard events). sucesos de puntero (pointer events), sucesos de cruce de ventana (window-crossing events) sucesos de focalización de la entrada (input focas events), sucesos de notificación del estado de asignación de las teclas (keymap state notification events), sucesos de exposición (expose events), sucesos de control de estructura (structure control events), sucesos de notificación del estado de la ventana (window state notification events), sucesos de notificación del estado del mapa de colores (colormap state notification events), y sucesos de comunicación entre clientes (client communication events). En todos los casos, los sucesos se asocian con una estructura de datos definida en el archivo de cabecera <X1 1 I Xlib.h> . Todas las estructuras de suceso contienen cinco campos que denotan el tipo de suceso, el número de la última petición procesada por el servidor, una indicación de si el suceso ha sido emitido por una petición de envío de suceso, y una indicación de la pantalla y ventana involucrada.

50

Ventanas y técnicas de Trabajo con ventanas

Capítulo 4


En el Capítulo 3, "Conceptos básicos y terminología", se presentaban los conceptos y terminología básicos de X Window excepto lo relacionado con un tema importante: las ventanas en sí. Como indica el propio nombre del producto, las ventanas son los componentes esenciales en el sistema X Window. En este capítulo se profundiza en las ventanas y en su manipulación.

Una analogía que se usa a menudo, compara las ventanas de una pantalla de visualización con un conjunto de hojas de papel sobre una mesa de escritorio. Esta analogía, como cualquier analogía, se debe de interpretar con cuidado. Por ejemplo, las ventanas, como los pedazos de papel, se pueden colocar en cualquier orden y mover de un lado para otro según se necesite. Sin embargo, las ventanas de X Window son habitualmente rectangulares y paralelas a la pantalla.

Otra analogía útil compara las interrelaciones entre ventanas con los individuos de un árbol familiar. X Window habla acerca de padres, hijos, hermanos, ascendientes y descendientes. Numerosos tecnicismos describen la geometría de una ventana, como la anchura de su borde, sus características permanentes, si está disponible para entrada y salida, y sus aspectos variables, como su color de fondo y cómo reacciona cuando su ventana padre cambia de tamaño.

El ciclo de vida de las ventanas abarca su creación, usando las funciones de creación de ventanas: la definición de sus características variables, la visualización de las ventanas en un momento dado y su destrucción cuando ya no tienen utilidad.

X Window proporciona numerosas funciones de manipulación de ventanas. Estas funciones están asociadas a tipos de sucesos específicos que el programa solicita para saber qué hacer y cuándo hacerlo. No hace falta decir que cada función puede generar en la práctica uno o más errores, bien por una mala codificación de la petición o bien porque el sistema en si no puede atender una petición determinada.

A diferencia de la mayoría de las mesas de trabajo, las pantallas visualizadas por X Window son a menudo compartidas por varios usuarios. Para mantener la situación bajo control en lugar de permitir a cada usuario el acceso a la propiedad de la valiosa ventana, el sistema X Window cuenta con una aplicación de cliente especial, el gestor de ventanas. Más adelante verá que a menudo la filosofia más eficiente consiste en indicarle de forma indirecta al gestor de ventanas cómo se quieren manejar las ventanas.

Conceptos básicos

En el capítulo anterior definimos seis recursos: ventanas, contextos gráficos, tipos de letras, cursores, mapas de colores y mapas de puntos. Como el mismo nombre del software sugiere, las ventanas son el recurso principal de X Window. Habitualmente, una ventana es un área rectangular de la pantalla, orientada en paralelo a los bordes de ésta.

51


Otros sistemas de ventanas fijan condiciones estrictas para la creación y manipulación de las ventanas. X Window, sin embargo, define las ventanas en los términos más amplios posibles y permite al diseñador utilizar estos bloques constituyentes como vea más conveniente. Según los pioneros del desarrollo del sistema X Window, una de sus principales guías al diseñar el sistema fue "Proporcionar mecanismos antes que normas. En particular, poner las decisiones sobre la interfaz de usuario en las manos del cliente". En otras palabras, permitir al cliente elegir la apariencia de la interfaz. Este concepto tan abierto de ventanas abiertas implica importantes consecuencias sobre el diseño.

Las aplicaciones X Window no están restringidas a una apariencia estándar. Los diseñadores de sistemas pueden utilizar sólo ventanas adosadas (tiled windows), colocadas una al lado de otra, O pueden utilizar ventanas superpuestas que permiten una interrelación dinámica de ventanas más sofisticada, ofreciendo un mejor servicio a los usuarios finales. Las herramientas en propiedad, como OSF/Motif y Open Look, proporcionan aplicaciones con una apariencia estándar.

Analogía del escritorio

Es común comparar las ventanas de un sistema X Window con hojas de papel puestas sobre un escritorio. Consideremos primero las similitudes:

Igual que las hojas de papel del escritorio, una ventana no es interesante en sí misma. La ventana muestra su contenido actual y acepta datos del usuario.

Hay una única ventana, llamada ventana raíz, que se corresponde con la superficie de la mesa en si o a la funda del block de papel. La ventana raíz no se puede borrar, mover, ni modificar de ningún modo.

Las ventanas no necesitan ser del mismo tamaño. Pero igual que los trozos muy pequeños de papel son inservibles, carece de sentido crear una ventana que es demasiado pequeña para ser legible.

Las ventanas pueden ser transparentes, permitiendo a los usuarios ver el contenido de ventanas subyacentes. La mayoría de las ventanas, como las hojas de papel, no son transparentes.

Unas ventanas pueden cubrir a otras. Una ventana visible en la pantalla puede ocultar completa o parcialmente a una o más ventanas situadas debajo de ella. La situación relativa de la ventana puede cambiar casi instantáneamente, dependiendo de las necesidades del usuario. Lo mismo que los usuarios mueven un mensaje urgente desde el fondo del montón a la cima, también pueden modificar el orden de las ventanas en una pantalla.

El contenido de las ventanas, como el de las hojas de papel, se puede almacenar para su posterior recuperación o se puede desechar.

También hay varias diferencias importantes entre los papeles de un escritorio y las ventanas. Entre ellas están las siguientes:

Aunque el papel puede tener cualquier forma, las ventanas son habitualmente rectangulares. Su tamaño puede cambiar durante la vida de la aplicación, pudiendo crecer, a diferencia del papel.

Las ventanas deben estar orientadas paralelamente a la pantalla. No pueden estar inclinadas.

Cualquier parte de la ventana que quede fuera de la pantalla no se puede ver.

52


La relación entre las ventanas está definida formalmente, a diferencia de la relación entre los pedazos de papel. La próxima sección introduce términos como raíz, padre, hija, jerarquía, y orden de apilamiento que expresan las relaciones, a veces complejas, entre las ventanas.

Dependiendo de las condiciones de trabajo, sobre un escritorio pueden trabajar varios individuos. Estos individuos pueden intentar conscientemente no estorbarse. Pueden, por ejemplo, asignar parte del escritorio para los papeles de cada individuo. Estas restricciones no existen en X Window. Sin embargo, lo mismo que el jefe de la oficina coordina los diversos trabajos, un gestor de ventanas coordina las actividades asociadas a las ventanas de varias aplicaciones.

Terminología básica

Antes de examinar las funciones especificas de Xlib que gobiernan la manipulación de ventanas y los sucesos correspondientes, es necesario definir la terminología básica relativa a las ventanas. Estos términos se utilizan a menudo al codificar las funciones Nib.

La ventana raíz (root) cubre la pantalla completa No se puede mover, redimensionar, ni destruir. Se corresponde con la superficie dei escritorio y sirve de base para todas las demás ventanas En la Figura 4- 1 se muestra la ventana raíz.

Figura 4-1 Ventana raíz

La jerarquía de las ventanas (window hierarchy) expresa la relación vertical entre las ventanas. La jerarquía de las ventanas se corresponde aproximadamente con un árbol genealógico. En l a Figura 4-1 se

53


muestra una pantalla simplificada con tres ventanas: la ventana raíz y dos ventanas pequeñas, A y B. Las ventanas A y B se llama hijas (children), o subventanas (subwindows), de la ventana raíz: son hermanas (sibling) entre sí. La ventana raíz es el padre (parent) o ventana padre (parent window) de las ventanas A y B. La ventana raíz es la ímica ventana que no tiene padre. Como en las familias humanas, un padre puede tener varios hijos, pero cada hijo tiene solamente un Único padre.

Raíz

Figura 4-2 Pantalla con tres ventanas

La relación entre ventanas padrehija se define explícitamente cuando se crea una ventana hija. La función XCreateSimpleWindow, usada en el programa "Hola Mundo" del Capítulo2', y la función más general XCreateWindow especifican la ventana padre cuando crean una ventana hija. Recordemos que en el programa "Hola Mundo" con la función XCreateSimpleWindow se específica DefaultRootWindow como la ventana padre. La función XReparentWindow cambia la paternidad de una ventana a otra ventana situada en la misma pantalla.

La jerarquía de ventanas puede extenderse a varias generaciones. La Figura 4-3 ilustra una familia de tres generaciones. Las ventanas A y B son las hijas de la ventana raíz. La ventana A es el padre de las ventanas Al y A2. Las ventanas B I, B2 y B3 son las hijas de la ventana B. Se conocen como ascendientes (ancestors) de una determinada ventana al padre, abuelo, y así sucesivamente. La ventana raíz es ascendiente de todas las ventanas de la pantalla. La ventana A es el ascendente de las ventanas Al y A2, también es el ascendiente de todas las hijas que sean creadas a partir de las ventanas Al y A2. Observen que la ventana A no es ascendiente de las ventanas B1, B2, B3, ni de ninguna de sus hijas.

(La función para cambiar de padre mencionada anteriormente podría, sin embargo, hacer que A fiera ascendiente de la ventana Si.)

Lo opuesto de ascendiente es descendiente (descendent) o inferior. Las ventanas B1, B2y B3 son descendientes de la ventana B y de la ventana raíz. Un aspecto clave de la relación ascendienteldescendiente es la posibilidad de heredar características de las ventanas como el fondo y el borde.


Las ventanas hijas mostradas en la Figura 4-2 no están superpuestas. Cada una tiene su propia área. La Figura 4-3 ilustra una situación más compleja sin ninguna ventana hermana superpuesta. La Figura 4-4 ilustra una situación común en la que se superponen dos hermanas. En donde la ventana A esté sobre la ventana B, sólo será visible el contenido de la ventana A (a menos que la ventana A tenga un fondo transparente). El orden de apilamiento (stacking order) describe la relación entre hermanas. En este caso, la ventana A está más alta que la ventana B en el orden de apilamiento. Esta relación no es permanente. Varias funciones Xlib cambian el orden de apilamiento de las ventanas. En la Figura 4-5 se muestran padres e hijas y una forma de ocultarse (obcure) o cubrirse unas a otras.

A o Figura 4-3 Pantalla con una familia de tres generaciones

Consideremos un ejemplo de reapilamiento de ventanas. En la Figura 4-6, la ventana B2 está parcialmente oculta por su ventana padre B y por otra ventana padre A. El objetivo es hacer completamente visible la ventana B2. En la primera etapa, mostrada en la Figura 4-7, pasamos arriba la ventana B y sus hijas. La ventana B se hace completamente visible y la ventana A está parcialmente oculta. Sin embargo, la ventana B2 todavía no está completamente visible. En la segunda y última etapa, ilustrada en la Figura 4-8, movemos la ventana B2 a la cima de la pila. Ahora la ventana B2 está completamente visible, ocultando parcialmente las ventanas padre B y A.

Conforme las ventanas se mueven o se crean, las áreas anteriormente visibles pueden llegar a cubrirse u ocultarse (la ventana A de la Figura 4-6 ha sido ocultada parcialmente por la ventana B en la Figura 4-7). Cuando esto ocurre, es necesario plantearnos la pregunta de sí debemos preservar la imagen oculta. Más adelante trataremos todo esto en la sección "Atributos de almacenamiento" de este capítulo.

55


I

Figura 4-4 Superposición de hermanas

r - - - - - - - - - - - I r - - - - - - - - - - -1 i El I I

I I I I I I """_

I :----I-

Raíz

r - - - - - - - - - - - I : E 3 I

I I I I I

1

Figura 4-5 Ventanas ocultas

56


r - - - - - ,

""""; i A 2 I iB2 i

!"""-;

I I I

I I I

B

I I I I I I I I " _

u I

R a i Z Al I ~""""~"""""I

I I

Figura 4-6 La ventana B2 doblemente oculta

r-----.

"""--; i A 2 I jB2 i i €31; I I I I I I I I I".

R.2 ti

I I

I I I I I I I I "_

I

Z Al I I """""""""_ I

L

Figura 4-7 La ventana B2 simplemente oculta

57


r - - - - - - - -

i F-l "-""-; i B l j

1 ti

B

I I I I I I I I "-

I

Al I """"_"""-"- I

Figura 4-8 La ventana B2 completamente visible

El contenido de una ventana puede ser cortado o limitado (clipped) por su padre, es decir, una imagen no se extenderá más allá de los bordes de la ventana. Si por ejemplo, intentamos dibujar una larga línea en la ventana A, como se muestra en la Figura 4-9, esta línea se extiende hasta el borde de la ventana. Se descartan todos los puntos situados fuera de los limites de la ventana asociados con el segmento de línea. Si la ventana A se ensancha, estos puntos (descartados) no reaparecen automáticamente.

Las funciones XCreateSimpleWindow y XCreateWindow crean ventanas. Sin embargo, la acción de crear una ventana no la hace visible. Antes de poder ver una ventana, debe ser visualizada (mapped). Las funciones Xlib XMapWindow, XMapRaised, y XMapSubwindows visualiza ventanas. Aun cuando es necesario visualizar una ventana antes de que se haga visible, esto no es suficiente para hacerla visible. Una ventana cuyos ascendientes están todos visualizados se conoce como dispuesta parar verse (viewable). Incluso una ventana dispuesta para verse puede no estar visible (puede estar oculta por una hermana). Otra posibilidad es que una ventana esté completamente cortada por un ascendiente, lo cual ocurre cuando permanece completamente fuera de los limites de un ascendiente. En este caso, la ventana permanece invisible. (Observemos que se puede crear una ventana hija fuera de los limites de la ventana padre: sin embargo, esta ventana no estará visible).

En resumen, una ventana es visible sólo si se satisfacen las siguientes condiciones:

0 Ella y todos sus ascendientes están visualizadas.

No está ocultada por una hermana.

No está completamente cortada por un ascendiente.

58


Raíz

Figura 4-8 Una línea cortada

Características de las ventanas

Ahora que conocemos bajo qué condiciones una ventana puede estar visible en la pantalla, es el momento de considerar las características que dan a una ventana su imagen particular. Estas características incluyen sus aspectos geométricos, como su anchura y altura; sus características permanentes, como su profundidad (número de bits por punto en sus imágenes), y sus características variables, como su fondo y color. Los diseñadores utilizan estas Características para proporcionar una interfaz de usuario más amigable.

Geometría de las ventanas La geometría (geometry) de una ventana está constituida por su tamaño, forma y posición dentro de su ventana padre. En Figura 4-10 se ilustran los siguientes aplicados a la geometría de la ventana:

origen (origin) La esquina superior-izquierda de la ventana, interior al borde.

x La posición horizontal de la esquina superior-izquierda de la ventana hija, respecto al origen de la ventana padre.

anchura (width) La posición vertical de la esquina superior-izquierda de la ventana hija, respecto al orden de la ventana padre.

59


altura (height) La posición vertical de la esquina superior-izquierda de la ventana hija, respecto al orden de la ventana padre.

anchura del borde La altura de la ventana medida en puntos, sin contar el borde. (border-width)

Anchura del borde del

padre

TI Origen de la ventana padre t A

I

- X

Anchura del barde de la hj a

l y hij a

V entana hj a I 4 V entana padre

Anchura del padre

Figura 4-10 Geometría de la ventana

Por definición, el origen es la posición x,y (0,O). La coordenada x se incrementa de izquierda a derecha mientras que la y de arriba a abajo.

Características propias de las ventanas

Se conocen como características propias (characteristics) a las características permanentes de una ventana, Se fijan en el momento de su creación. La función XCreateSimpleWindow utiliza valores por omisión para las características propias de las ventanas que crea, mientras que XCreateWindow, la función más potente de Xlib, permite fijar los valores apropiados.

Clase

Existen dos clases de ventanas: Inputoutput (Entrada Salida) e InputOnly (Sólo Entrada). Las ventanas normales pertenecen a la clase Inputoutput. Las ventanas Inputonly son invisibles. Se usan en la gestión de la pantalla y permiten sucesos del ratón y teclado directos. Las ventanas InputOnly no tienen muchos de los atributos que vamos a discutir en las siguientes secciones (no tiene mucho sentido hablar del borde o color de una ventana invisible). La función XCreateSimpleWindow crea solamente ventanas Inputoutput, mientras que la función XCreateWindow crea ventanas Inputoutput e InputOnly.

60


Profundidad

La profundidad (deph) de una ventana es el número de bits por punto para sus valores de punto. Las ventanas Inputonly deben tener una profundidad O, o se producirá un error. Las ventanas Inputoutput pueden tomar diferentes valores de Profundidad, dependiendo de la estación de trabajo que se use. Los programadores experimentados codifican la profundidad de una ventana con el valor CopyFromParent de forma que la aplicación se pueda transportar desde un tipo de estación de trabajo a otra sin tener que volver a escribir el código. La función XDefaultDepth devuelve la profundidad de la ventana raíz. La función XListDepths devuelve una lista de profundidades disponibles en una determinada estación de trabajo.

Visual

Se conoce como visual (visuals) al modo en que una estación de trabajo maneja la salida a través de la pantalla. Entre los elementos del visual se incluyen el color y el número de puntos por bit. Las estaciones de trabajo sofisticadas permiten a la aplicación seleccionar el visual para cada venta. Esta característica permite una salida a medida para la aplicación pero requiere una cuidadosa codificación de modo que las aplicaciones puedan llevarse a estaciones de trabajo menos sofisticadas.

Atributos de las ventanas

Se conocen como atributos (attributes) a las características modificables de una ventana. Entre estos atributos se incluyen el fondo de la ventana, el borde, la disposición de imágenes cuando cambia el tamaño de la ventana; el mecanismo de almacenamiento, si lo hay, para preservar el contenido de las ventanas cubiertas por otras ventanas, y el modo mediante el cual la ventana maneja los suceso, mapas de colores , y cursores. En las siguientes secciones se tratan los atributos individualmente. La sección "Cambiar los atributos de las ventanas'' presenta el procedimiento para fijar y cambiar los atributos de una ventana.

Atributos del fondo

El fondo de la ventana está especificado por los valores codificados de los atributos background-pixrnap o backgroundqixel. El atributo backgrounqixel genera un fondo continuo. El atributo backgroundqixmap genera un fondo con un patrón de repetición. Cuando backgroundgixmap tiene un valor None, genera un fondo transparente, permitiendo a los usuarios ver el contenido de las ventanas ocultas. Un atributo backgroundgixmap que tenga el valor ParentRelative da a una ventana el mismo fondo que el de su padre. Si la ventana hija se mueve respecto a su padre, el contenido de la hija se debe volver a dibujar. El tamaño del mapa de puntos del fondo afecta a la velocidad de dibujo de la ventana, cuando se usan mapas de puntos grandes e irregulares se ha de esperar una gran pérdida de rendimiento.

El sistema genera el patrón de fondo seleccionado cuando toda o parte de la imagen de una ventana se borra y siempre que una ventana previamente oculta se convierte en visible. El suceso Expose informa al cliente si una imagen necesita ser redibujada.

Atributos del borde

Especificar los atributos del borde es similar a especificar los atributos del fondo. Para seleccionar un borde sólido se ha de especificar el valor bordergixel. Para seleccionar un borde con un patrón repetitivo, especifique el valor bordergixmap. El atributo CopyFromParent establece el borde de una ventana hija como el de su padre. Dándole al campo border-width el valor O en las funciones XCreateSimpleWindow o XCreateWindow eliminaremos el borde.

61


Las salidas gráficas se cortan siempre abarcando sólo el interior de la ventana afectada. Así la salida no afecta al borde de la ventana.

Atributos de atracción

El reposicionamiento de una ventana hija respecto a su ventana padre se dice que se realiza mediante la atracción de ventana (window gravity). El reposicionamiento de la imagen de una ventana respecto a una ventana redimensionada se dice que se realiza mediante la atracción de bit (bit gravity). En ambos casos, el área afectada es atraída por el centro, un borde, o una esquina de la ventana.

Este proceso es semejante a la gravedad de la física, excepto en que los objetos pueden caer hacia arriba O

hacia el lado, así como bajar.

Las direcciones de atracción se nombran como los ocho puntos de una brújula. Cuando a los atributos bitxravity o win_gravity de una ventana se les da el valor NorthWestGravity (Atracción noroeste), la imagen o la ventana hija se acerca a la esquina superior-izquierda de la ventana padre redimensionada. La Figura 4-1 1 muestra los ocho valores posibles de la atracción. La estación de trabajo genera sucesos Expose para señalar la existencia de nuevas áreas en una ventana si se incrementan sus dimensiones. Por ejemplo, consideramos la Figura 4-12, para la que se seleccionó NorthWestGravity. En este caso, los sucesos Expose señalan las áreas de abajo y a la derecha de la imagen mostrada.

NorihWertCrmrity

WestCrmriy

SouihCravity

Figura 4-11 Los ocho valores posibles de los atributos de atracción.

62


NorlhWestGrwily Figura 4-12 La atracción y los sucesos Expose

X Window no puede redimensionar una imagen de forma que ocupe la misma fracción de la ventana completa. Si se decide volver a dibujar la imagen, para así mantener su tamaño relativo respecto a la ventana, deberemos seleccionar el valor por omisión del atributo bitxravity ForgetGravity, el cual borra la imagen. Los sucesos Expose le indicarán que la imagen habrá de ser redibujada.

Además de las ocho posiciones de la brújula y el valor ForgetGravity, el atributo bitxravity puede tomar los valores CenterGravity, que centra la imagen en la ventana modificada, y StaticGravity, que deja fija la imagen respecto a la ventana raíz. La opción StaticGravity se usa sólo si la ventana cambia de tamaño y posición al mismo tiempo.

Cuando una ventana padre cambia de tamaño, se utilizan tanto su atributo bitzravity como el atributo bitxravity de sus hijas. Las ventanas hijas generan uno o más sucesos ConfigureNrotify y después GravityNotify. El atributo wing-avity permite el valor especial UnmapGravity, el cual causa la desaparición de la visión de la ventana hija pertinente, cuando su ventana padre es redimensionada. Si tenemos la intención de reescalar la propia ventana hija, debemos usar esta opción para evitar que se vea la ventana antes de cambiar su tamaño.

Atributos de almacenamiento

Si es el mismo servidor X quien mantiene el contenido de la ventana, el conjunto de puntos almacenados recibe el nombre de área de almacenamiento de reserva (backing store). No todas las implementaciones de X Window incluyen un área de almacenamiento, encontrándose los programadores a menudo que éste es fisicamente demasiado pequeiío para satisfacer sus necesidades. La dependencia del área de almacenamiento puede reducir la portabilidad de una aplicación a otras estaciones de trabajo. Por lo que se les sugiere a los programadores que prevean guardar ellos mismos las imágenes.

Relacionados con esta área de reserva se dispone de tres valores de atributo: Notuseful (valor por omisión), WhenMapped, y Always. El valor NotUseful indica que el área de almacenamiento no es utilizada por esta ventana particular. El valor WhenMapped indica que es útil sólo cuando la ventana está visualizada. Con el valor Always se indica que se mantendrá el área de almacenamiento aunque la ventana no se encuentre visualizada. Este valor se podría usar, por ejemplo, cuando la ventana es más grande que su padre.

Algunos servidores conservan el contenido de las ventanas seleccionadas bajo otras ventanas. Este proceso se conoce como almacenar zonas ocultas (save unders). Este contenido se utiliza sólo si la imagen de la pantalla completa en el momento de la restauración permanece igual que cuando se guardó. Se usa a menudo con ventanas dinámicas.

Los atributos backingqlanes y backinggixel se utilizan conjuntamente para reducir el tamaño del área de almacenamiento requerida para guardar una imagen. El atributo backingqlanes indica aquellos bits de

63


cada punto que se deben guardar en su totalidad. A los planos restantes se les da el valor de backiinggixel.

Atributos del procesamiento de sucesos

La máscara de sucesos, introducida en el Capítulo 2, “El programa Hola Mundo”, y discutida en detalle en el Capítulo 3, “Conceptos básicos y terminología”, indica los sucesos de más interés para una ventana determinada, o en algunos casos, para los descendientes de la ventana. Habitualmente los sucesos se propagan desde una ventana a sus ascendientes. Esto significa que si un determinado suceso no es seleccionado por una ventana, éste pasa a sus ascendientes hasta encontrar la ventana para la que se ha seleccionado el suceso. La máscara do-notgropagate define los sucesos a bloquear.

El atributo lógico override-redirect puede tomar los valores TRUE (VERDADERO) o FALSE (FALSO, valor por omisión). Cuando es TRUE, el gestor de ventanas no interviene en las operaciones de visualización. configuración, o de cambio de orden de las ventanas. El valor usual para los menús dinámicos es TRUE.

Atributos del mapa de colores

El atributo colormap especifica el mapa de colores optimo para una ventana Inputoutput. El mapa de colores seleccionado debe tener el mismo tipo visual que la ventana en cuestión. La opción CopyFromParent se debe usar si la ventana hija tiene el mismo tipo visual que la ventana padre. Se ha de tener cuidado, ya que los cambios hechos en el mapa de colores después de la operación de copia no afectan al mapa de colores del hijo.

Atributos del cursor

El atributo del cursor especifica el cursor a usar cuando el puntero está en una ventana. Si el cursor se establece a None, se usa el de la ventana padre. Si se cambia el cursor padre provocaremos un cambio en el cursor de la ventana hija.

Ciclo de vida de las ventanas Las etapas más importantes en la vida de una ventana son su creación, visualización y destrucción. La creación de la ventana define la relación de esta con su padre e, implícitamente, con sus hermanas. Con ella establecemos la geometría, características y atributos de la ventana. Para que la ventana sea visible, se requiere su visualización. La destrucción de la ventana la elimina y devuelve sus recursos al sistema. En la Tabla 4-1 se listan los posibles sucesos y errores generados para cada una de las funciones de ventana discutidas en el texto.

Creación de ventanas X Window suministra dos funciones Xlib para crear ventanas. La función XCreateSimpleWindow crea una ventana Inputoutput que hereda algunas de las características y atributos de sus padres. La función XCreateWindiow crea una ventana cuyas características y atributos deben ser fijados.

Tabla 4-1. Tabla de funciones, sucesos y errores de las ventanas

Funci6n Suceso(s) problernas(s) Error(es) posible(s)

XCreateWindow CreateNotify, VisibilityNotify

BadAlloc, 8adColor. Badcursor, BadMatch, Badpixmap, Badvalue, BadWindow

64


XCreateSimpleWindow

XDestroyWindow

XDestroySubwindows

XMapWindow

XMapRaised

XMapSubwindows

XUnmapWindow

XlUnmapSubwindows

XConfigureWindow

XMoveWindow

XResizevWindow

XMoveResizeWindow

CreateNotify

DestroyNotify. Expose

DestroyNotify, Expose

MapRecuest, MapNotifv, Expose



UnmapNotify, Expose

UnmapNotify, Expose

ConfigureRequest, SizeRequesf ConfigureNotify, GravityNotify,

Expose, ConfigureRequest



BadAlloc. BadMatch, Badvalue, BadWindow

BadWindow

BadWindow

BadWindow

BadWindow (múltiple)

BadWindow

BadWindow

BadWindow

BadMatch,BadValue BadWindow

BadWindow

Badvalue, BadWindow

Badvalue. BadWindow

Tabla 4-1. Tabla de funciones, sucesos y errores de las ventanas

Funci6n Suceso(s) problemas(s)

XSetWindowBorderWidth

XRaiseWindow Expose, ConfigureRequest

XLowerWindow Expose, ConfigureRequest

XCirculateSubwindows CirculateRequest, CirculateNotify, Expose

XCirculateSubwindowsUp CirculateRequest, CirculateNotify, Expose

XCirculateSubwindowsDown CirculateRequest, CirculateNotify, Expose

XRestackWindows ConfigureRequest, Expose

XChangeWindowAttributes

XSetWindowBackground

XSetWindowBackgroundPixmap

Error(es) posible(s)

BadWindow

BadWindow

BadWindow

Badwindow, BadValue

BadWindow

BadWindow

BadMatch, BadWindow

BadAccess, Badcolor, Badcurso, BadMatch, 8adPixrnap. Badvalue, BadWindow

BadMatch, BadWindow

BadMatch, Badpixmap BadWindow

65


XSetWindowBorder XSetWindowBorderPixmap

XSetWindowColormap

XdefineCursor

ColorMapNotify

BadMatch, BadWindow BadMatch, Badwindow, BadPixmap

Badcolor, BadMatch, BadWindow Badcursor, BadWindow

XundefineCursor BadWindow

La función XCreateSimple Window

La función XCreateSimpleWindow genera una forma de petición del protocolo unidireccional y devuelve el identificador de recurso ventana thewindow a usar en referencias subsiguientes. El segundo parámetro de la función es la ventana padre, en este caso la ventana raíz de la misma pantalla (monitor).

La idea se discutió brevemente en el Capítulo 2. "E1 programa Hola Mundo", y se explicará con mayor detalle posteriormente en este capítulo. La función XCreateSimpleWindow es como sigue:

Window XcreateSimpoleWindow (display, parent, x, y, wiwidth, height, border-width, border, background)

Display *display; Window parent; int x, y;

I* Estructura de vinualisacl6n *I I* identificador de la ventana padre *I I* Coordenada de la esquina *I

la ventana creada *I

unsigned int width, height; I* Dimensi6n de la ventana *I unsigned int border-width; I* Anchura del borde en puntos *I unsigned long border; I* Valor de punto del borde *I unsigned long background; I* Valor de punto del fondo *I

Por ejemplo. se llamaría a la función:

thewindow = XCreateSimpleWindow(thedisplay, DefaultRootWindow(thedisplay), thehint.x, thehint.y, thehint.width, thehint.height, 7, theforeground, thebackground);

La función XCreateSimpleWindou crea una ventana hija no visualizada en la cima de la pila. Como la ventana no está visible, no ocultará a ninguna hermana. El padre y la ventana hija recién creada tiene mucho en común. Comparten la misma pantalla. La ventana hija está posicionada con respecto al padre (esto es, con respecto a sus coordenadas x e y). Cuando el padre se mueve, la hija se mueve junto con él. La hija hereda las características y atributos de su padre.

La función XCreateSimpleWindow hace que el servidor genere un suceso CreateNotify. Puede producir los errores BadAlloc, BadMatch, BadValue y Badwindow.

La función XCreate Window

La función XCreateWindow es más general que la función XCreateSimpleWindow. La función XCreateWindow permite especificar las características y atributos de la ventana. Antes de llamar a esta función debemos declarar una estructura de datos XSetWindowAttributes, asignarle con los valores elegidos, y dar los valores adecuados a los bits de una mascara asociada. Hemos de tener cuidado ya que los valores por omisión pueden causar sorpresa no muy agradables. A continuación mostramos esta función:

66


Window XcreateWindow (display, parent, x, y, width, height, border, width, depth, class, visual, valuemask, attributes)

Display *display; Window parent; int x,y;

I* Estructura de visualizaci6n *I /* Ventana padre *I /* Coordenadas de la esquina

superior izquierda del borde de la ventana creada *I

unsigned int width, height; /* Dimensiones de la ventana *I unsigned int border-width; I* Anchura del borde en puntos */ unsigned in depth; I* Profundidad de la ventana en

puntos *I

unsigned in class; I* Inputoutput, InputOnly,

Visual visual; I* Tipo de visual *I unsigned long valuemask; I* Mascara para los atributos de

XSetWindowAttributes attributes; I* Atributos de la ventana *I

CopyFromParent *I

la ventana *I

La función XCreateWindow hace que el servidor genere un suceso CreateNotify. Puede dar los errores BadAlloc, Badcolor, Badcursor, BadMatch, BadPixmap, Badvalue, y Badwindow.

Asignación de valores a los atributos

Para dar un valor a un atributo de una ventana, debemos aplicar la orden OR a la máscara de bits apropiada de la lista siguiente, darle el valor a la estructura de datos XSetWindowAttriibutes, y llamar a la función XCreateWindow.

La estructura de datos XSetWindowAttributes es como sigue:

I* Valores de la mascara de bits de los atributos de ventanas *I

#define CWBackPixmap #define CWBackPixel #define CWBorderPixmap #define CWBorderPixel #define CWBitGravity #define CWWinGravity #define CWBackingStore #define CWBackingPlanes #define CWBackingPixel #define CWOverrideRedirect #define CWSaveUnder #define CWEvenMask #define CWDontPropagate #define CWColormap #define CWCurrsor I* Valores *I typedef struct {

Pixmap backgroundgixmap;

unsigned long background-pixel; Pixmap border-pixmap;

(1L << O) (1L << 1) (1L << 2) (1L << 3) (1L << 4) (1L << 5)

(1L << 7)

(1L << 9) (1L << 10) (1L << 11) (1L << 12)

(1L << 6)

(1L << 8)

(1L << 13) (1L << 14)

I* Background, None, o ParentRelative *I

I* Punto del fondo *I I* Borde de la ventana o

CopyFromParent *I

67


unsigned long border-pixel; Int bitxravity;

Int win-gravity

int backingstore;

unsigned long backingglanes; unsigned long backingpixel;

Bool save-under

long event-mask; long do-notgropagate-mask;

Bool override-redirect; Colormap color map;

Cursor cursor; } XSetWindowAttributes;

I* Valor de punto del border *I I* Selecci6n del valor de

atracci6n del bit *I I* Selecci6n del valor de

atracci6n de la ventana *I I* Notuseful, WhenMapped,

Always *I I* Planos a presevar si es posible *I I* Valor de punto para restaurar

I* TRUE (DVERDADERO), guarda plano *I

los bits a causa de mCnus dinhmicos *I

I* Establecer los sucesos a guardar *I I* Establecer los sucesos a no

I* TRUE, no tener en cuenta *I I* Mapa de colores asociados

I* Cursor a visualizar *I

propagar *I

con la ventana *I

En la Tabla 4-2 se listan los recursos y sus valores por omisión, indicando si están definidos para las ventanas InputOnly.

Nota. Todos los atributos mostrados en la Tabla 4-2 se utilizan con las ventanas Inputoutput.

Visualización de ventanas

Una ventana y todos sus ascendientes antes de que se puedan ver en la pantalla deben ser visualizadas. Como veremos más adelante en este capítulo, el gestor de ventanas puede tomar un papel activo en la visualización de una ventana, relevando al programa de aplicación de tareas tales como el dimensionamiento y colocación de las ventanas. Nib incluye tres funciones para visualizar ventanas y dos funciones para cancelar la visualización.

Tabla 4-2. Atributos de recurso.

Atributo Valor por omisi6n

backgroundgixmap background pixel bordergixmap bordergixel bit-gravity win-gravity backing-store backingglanes backing pixel save-under event-mask donotgropagate-mask override-redirect colormap cursor

None (Ninguno) No definido CopyFromParent No definido ForgetGravity NorthWestGravity Notuseful Todos a uno Cero FALSE Conjunto vació Conjunto vació FALSE CopyFromParent None (Ninguno)

InputOnly

No No No No No Si No No No No Si Si Si No Si

68


Funciones de visualización de ventanas

Para visualizar las ventanas se usan las funciones XMapWindow, XMapRaised, y XMapSubWindows.

La función XMapWindow visualiza la ventana especificada y todas sus subventanas con peticiones de visualización. Esta función genera sucesos Expose. MapNotify o MapRequest. En general, la ventana se visualiza una vez que el programa examina el suceso Expose asociado, como se ve en el programa "Hola Mundo" del Capítulo 2. E1 programa "Hola Mundo", la función XMapWindow, que vernos a continuación, puede generar un error Badwindow:

XMapWindow(display, w) Diaplay *display; /* Estructura de visualizaci6n */ Window w; /* ID de la ventana */

La función XMapRaised visualiza la ventana especificada y todas sus subventanas que tienen peticiones de visualización. Además, eleva la ventana especificada a la cima de su pila de ventanas. A continuación mostramos la función XMapRaised, esta puede generar varios errores Badwindow.

XMapRaised(display,w) Diaplay *display; /* Estructura de visualizaci6n */ Window w; /* ID de la ventana */

La función XMapSubwindows visualiza todas las subventanas de una ventana seleccionada. El orden en la pila es de arriba abajo. Esta función genera sucesos Expose para cada ventana conforme se visualiza cada una. Una sola función XMlapSubwindows tiende a ser más eficiente que un grupo de funciones XMapWindow, porque la función XMapSubwindows lleva a cabo muchas operaciones para el grupo de ventanas de una sola vez, mientras que la función XMpWindow debe llevar a cabo estas operaciones individualmente para cada ventana afectada. La función XMapSubWindows, que se muestra a continuación, puede generar un error Badwindow.

XMapSubwindowe(display, w) Display *display; /* Estructura de visualizaci6n *I Window w; /* ID de la ventana */

Funciones para cancelar la visualización de ventanas

Las funciones XUnmapWindow, y XUnmapSubuwindows se usan para cancelar la visualizacidn (unmapping) de las ventanas. Al cancelar la visualización de una ventana ésta, y todos sus descendientes se hacen invisibles en la pantalla. Una ventana que deja de estar visualizada no pierde su lugar en la pila.

La función XUnmapWindow cancela la visualización de una sola ventana. Esta función genera un suceso UnmapNotify (Notificación de no visualización) para la propia ventana y sucesos Expose para las ventanas que previamente quedaron ocultas por esta ventana. La función XUnmapWindow, que se muestra a continuación, puede generar un error Badwindow.

XUnmapWindow(display, w) Display *display; /* Estructura de visualizaci6n */ Window w; /* ID de la ventana */

La función XunmapSubwindows, cancela la visualización de todas las subventanas de la ventana especificada, comenzando por el fondo de la pila. Una única función XUnmapSubwindows se ejecuta más rápido que varias funciones XUnmapWindow. Esta función genera un suceso UnmapNotify para la propia ventana y sucesos Expose para las ventanas que previamente quedaron ocultas por la ventana que ha dejado de estar visualizada. Esta función, que mostramos a continuación, puede generar un error Badwindow.

69


XUnmapSubwindows(display, w) Display *display; /* Estructura de visualizaci6n */ Window w; /* ID de la ventana */

Destrucción de ventanas

En una aplicación se pueden destruir ventanas implícitamente al cerrar la conexión de visualización con el monitor o explícitamente mediante una de las dos funciones Xlib siguientes. Las ventanas se destruyen comenzando por el fondo de la jerarquía y continuando hasta la cima.

La fmción XDestroyWindow destruye la ventana especificada y todas sus subventanas. Genera un suceso DestroyNotify por cada ventana destruida. Si la destrucción de una ventana hace visibles otras, la función genera los sucesos VisibilityNotify y Expose correspondientes.

La función XDestroyWindow, que se muestra a continuación, puede generar un error Badwindow.

XDestroyWindow(display, w) Display *display; /* Estructura de visualizaci6n *I Window w; /* ID de la ventana */

La función XDestroySubwindows destruye todas las subventanas de la ventana especificada, pero no destruye la propia ventana. Genera un suceso DestroyNotify por cada ventana destruida. Si la destrucción de un a ventana hace visibles a otras, la función genera los sucesos VisibilityNotify y Expose apropiados. Una única función XDestroySubwindows se ejecuta más rápido que varias fimciones XDestroyWindow. La función XDestroySubwindows, que se muestra a continuación, puede generar un error Badwindow.

XDestroySubwindow(display, w) Display *display; /* Estructura de visualizaci6n *I Window w; /* ID de la ventana */

Funciones de configuración de ventanas

Las funciones descritas en la sección anterior les permiten a los usuarios crear, visualizar, cancelar la visualización, y destruir ventanas. Pero no permite el control de la aplicación. En esta sección se describe las funciones de configuración, desplazamiento y redimensionamiento de ventanas, así como cambiarla de posición en la pila. A continuación se describen las funciones que modifican la geometría de una ventana. La sección concluye presentando una petición que por sí solo cambia tanto el orden de la ventana en la pila como su geometría.

Desplazamiento y redimensionamiento de ventanas

Hay funciones Xlib que les permiten a las aplicaciones mover y redimensionar ventanas, tanto por separado como a la vez. Estas funciones son XMoveWindow, Resizewindow, y XMoveResizeWindow.

La función XMoveWindow mueve la ventana seleccionada a una nueva posición especificada mediante coordenadas x e y. Estas coordenadas referencian al punto superior-izquierdo del borde de la ventana o de la propia ventana si no tiene borde. Si la ventana es visible, se puede perder su contenido si en su nueva

70


posición pasa a estar oculta y no hay área de almacenamiento ni se guardan las zonas ocultas. En este caso, el servidor generará sucesos Expose para informar a la aplicación interesada. Si las ventanas después del desplazamiento dejan de estar ocultas, el servidor generará los sucesos Expose necesarios. Si el bit de la máscara de la ventana override-redirect está en FALSE y otro cliente ha asignado una máscara de sucesos SubstructureRedirectMask a la ventana padre, el servidor generará un suceso ConfigureRequest, sin cambiar de tamaño la ventana. La función XMoveWindow, que se muestra a continuación, puede generar un error Badwindow.

XMoveWindow(display, w) Display *display; I* Estructura de visualizaci6n *I Window w; I* ID de la ventana *I int x,y; I* coordenadas *I

La función XResizeWindow cambia las dimensiones interiores de la ventana seleccionada pero no cambia sus bordes. Tampoco cambia el origen de la ventana ni su posición en el orden de la pila. Al cambiar el tamaño de la ventana se puede perder su contenido, en cuyo caso la función genera sucesos Expose. Si al disminuir de tamaño una ventana visible, dejando de estar cubiertas áreas anteriormente ocultas de otras ventanas, la función genera los sucesos Expose apropiados. Será responsabilidad de la aplicación el distinguir entre los diferentes sucesos Expose y ejecutar la acción apropiada. Si el bit de la máscara de la ventana overrideredirect está en FALSE y otro cliente ha asignado una máscara de sucesos SubstructureRedirectMask a la ventana padre, el servidor generará un suceso ConfigureRequest, sin mover la ventana. La función XResizeWindow, que se muestra a continuación, puede generar los errores BadValue y Badwindow.

XResizeWindow(display, w, width, heigth) Display *display; I* Estructura de visualizaci6n *I Window w; I* ID de la ventana *I unisgned int width, heigth; I* Dimensiones interiores de la ventana *I

La función XMoveResizeWindow cambia las dimensiones interiores y la posición de la ventana seleccionada pero no cambia su borde ni su posición en el orden de apilamiento. Al cambiar de tamaño la ventana, se puede perder su contenido, en cuyo caso la función generará sucesos Expose. Si al disminuir de tamaño una ventana visible, dejando de estar cubiertas áreas anteriormente ocultas de otras ventanas, la función generará los sucesos Expose apropiados. Si el bit de la máscara de la ventana override-redirect está en FALSE y otro cliente ha asignado una máscara de sucesos SubstructureRedirectMask a la ventana padre, el servidor generará un suceso ConfigureRequest, no moviendo ni redimensionando la ventana. La función XMoveResizeWindow, que se muestra a continuación, puede generar los errores BadValue y Badwindow.

XMoveResizeWindow(display, w, x, y, width, heigth) Display *display; I* Estructura de visualizaci6n *I Window w; I* ID de la ventana *I int x,y; I* coordenadas *I unisgned int width, heigth; I* Dimensiones interiores de la ventana *I

Establecimiento de la anchara del borde de las ventanas

La función XSetWindowBorderWidth fija la anchura del borde de la ventana. Esta es una de las pocas funciones Xlib que no genera ningún suceso. La función XSetWindowBorderWidth, que se muestra a continuación, cambia la anchura del borde de una ventana, pudiendo generar un error Badwindow.

XSetWindowBorderWidth(display, w, x, y, width) Display *display; I* Estructura de visualizaci6n *I Window w; I* ID de la ventana *I unsigned int width; I* Anchura del borde de la ventana *I

71


Modijicación del orden de apilamiento de las ventanas

Existen funciones Xlib que les permiten a las aplicaciones ascender, descender, rotar o reapilar en la pila las ventanas, Estas funciones son XRaiseWindow, XLowerWindow, XCirculateSubwindows, XCirculateSubwindowsUp, XCirculateSubwindowsDown, y XRestackWindows.

La función XRaiseWindow asciende o eleva (pops) la ventana especificada a la cima de la pila. Si la ventana está visualizada, al ejecutar esta función se pueden generar sucesos Expose para la ventana dada y para cualquier subventana visualizada que pase a estar oculta. Si el bit de la máscara de la ventana banderín override-redirect está establecido como FALSE y otro cliente ha asignado una máscara de sucesos SubstructureRedirectMask a la ventana padre, el servidor generará un suceso ConfigureRequest, no subiendo la ventana. La función XRaiseWindow, que se muestra a continuación, puede generar un error Badwindow.

XRaiseWindow(display, w) Display *display; I* Estructura de visualizaci6n *I Window w; I* ID de la ventana *I

La función XLowerWindow desciende o empuja (pushes) la ventana especificada al fondo de la pila. Si la ventana está visualizada, la ejecución de esta función generará sucesos Expose para cualquier hermana visualizada que estuviera ocultada. Si el bit de la máscara de la ventana override-redirect está establecido como FALSE y otro cliente ha asignado una máscara de sucesos SubstructureRedirectMask a la ventana padre, el servidor generará un suceso ConfigureRequest, no descendiendo la ventana. La función XLowerWindow, que se ofrece a continuación, puede generar un error Badwindow.

XLowerWindow(display, w) Display *display; I* Estructura de visualizaci6n *I Window w; I* ID de la ventana */

Para dominar el uso de las funciones de circulación de ventanas XCirculateSubwindows, XCirculateSubwindowsUp y XCirculateSubwindowsDown es necesario comprender el término técnico obstruir (occlude). La ventana I obstruye a la ventana J si ambas ventanas están visualizadas (no forzosamente visibles), si I está por encima de I en el orden de apilamiento, y si el rectángulo definido por el borde exterior de I (la ventana incluye al borde) corta al rectángulo definido por el borde exterior de J.

Nota. La obstrucción de ventanas es similar a, pero no exactamente lo mismo que, la ocultación de ventanas.

La tünción XCirculateSubwindows hace rotar a los hijos de la ventana especificada en la dirección seleccionada. El parámetro RaiseLowest asciende a la cima del orden de apilamiento a la hija visualizada más baja obstruida por otra hija. El parámetro LowerHighest desciende al fondo del orden de apilamiento a la hija visualizada más alta que obstruye a otra hija. En ambos casos, se generan y procesan sucesos Expose para las ventanas que estaban previamente ocultas.

Si el bit de la máscara de la ventana override-redirect está en FALSE y otro cliente ha asignado una máscara de sucesos SubstructureRedirectMask a la ventana padre, el servidor generará un suceso ConfigureRequest, y no realizará la rotación de las ventanas. La función XCirculateSubWindows,. que se muestra a continuación, puede generar los errores BadValue y Badwindow.

XCirculateSubwindows(display, w, direction) Display *display; I* Estructura de visualizaci6n *I Window w; I* ID de la ventana *I int direction; I* RaiseLowest o LowerHighets *I

72


La función XCirculateSubwindowsUp es una función equivalente a la función XCireulateSubwindows dándole al parámetro direction el valor RaiseLowest. La función XCireulateSubwindowsUp, que se ofrece a continuación, puede generar un error Badwindow.

XCirculateSubwindowsUp(display, w) Display *display; I* Estructura de visualizaci6n *I Window w; I* ID de la ventana */

La hnción XCireulateSubwindowsDown es una función equivalente a la h c i ó n XCirculateSubwindows dándole al parámetro direction el valor LowerHighest. La función XCirculateSubwindowsDown, que mostramos a continuación, puede generar un error Badwindow.

XCirculateSubwindowsDown(display, w) Display *display; I* Estructura de visualizaci6n *I Window w; I* ID de la ventana *I

La función XRestackWindows reordena la pila de ventanas según el orden especificado de arriba abajo La situación en la pila de la primera ventana no se ve afectada, pero las siguientes ventanas de la lista se colocan por debajo de la primera ventana según especifique dicha lista.

Si el bit de la máscara override-redirect de alguna de las ventanas referencidas está en FALSE y otro cliente ha asignado una máscara de sucesos SubstructureRedirectMask a la ventana padre, el servidor generará un suceso ConfigureRequest para cada ventana cuyo bit de máscara este en FALSE y no tendrá lugar la reordenación de las ventanas. A continuación mostramos la función XRestackWindows que puede generar los errores BadMatch y Badwindow.

XRestackWindows(display, windows, nwindows) Display *display; I* Estructura de visualizaci6n *I Window windows [ 1; I* Lista de ventanas a reordenar *I int nwindows: I* Numero de ventanas a reordenar */

Modificación de los atributos y conjiguración de la ventana

Como se expuso anteriormente, se conocen como atributos a las características no permanentes de una ventana. Entre los atributos de una ventana están su fondo, borde, y atracción. X Window proporciona dos formas de cambiar los atributos de las ventanas: Se puede usar la función XChangeWindowAttributes, que permite cambiar aquellos atributos cuyos valores residan en la estructura de datos XSetWindowAttributes asociada, a los que se fijan sus valores de bit a partir de la máscara de valores asociada, o bien usar funciones individuales como XSetWindowBackground.

La funcio'n XChange WindowAttributes

La función XChangeWindowAttributes cambia simultáneamente uno o más atributos de una ventana. Cambiar los atributos de una ventana es similar a establecer los atributos de la ventana mediante la función XCreateWindow Para cambiar el valor de un atributo de ventana, utilice la orden OR sobre el bit de máscara apropiado, asígnele el valor adecuado en la estructura de datos XSetWindowAttributes, y llame a la función XChangeWindowAttributes. A continuación vemos la función XChangeWindowAttributes que puede generar los errores BadAccess, Badcolor, Badcursor. BadMatch, BadPixmap. Badvalue, y Badwindow.

73


XChangeWindowAtrributes(display, w, valuemask, attributes) Display *display; /* Estructura de visualizaci6n *I Window w; I* ID de la ventana *I unsigned long valuemask; I* MPscara para los atributos de ventana *I

XSetWindowAttributes *attributes I* Atributos de la ventana *I

Modijkación de los atributos individuales de las ventanas

La función XSetWindowBackground fija un valor determinado de punto para el fondo de la ventana. Esta operación no cambia el contenido de la ventana. La función XSetWindowBackground, que se muestra a continuación, puede generar los errores BadMatch y Badwindow.

XSetWindowBackground(display, w, backgroundgixel) Display *display; I* Estructura de visualiaci6n *I Window w; I* ID de la ventana */ unsigned long background-pixel; /* Punto del fondo */

La función XSetWindowBackgroundPixmap asigna el mapa de puntos especificado al fondo de la ventana. Esta operación no cambia el contenido de la ventana. Cuando se pasa el parámetro ParentRelative, se usa el mapa de puntos del fondo del padre. A continuación se muestra la función XSetWindowBackgroundFixmap, que puede generar los errores BadMatch, BadPixmap y Badwindow.

XSetWindowBackgroundPixmap(display, w, backgroundgixmap) Display *display; /* Estructura de visualiaci6n *I Window w; I* ID de la ventana *I unsigned long backgroundgixmap; /* Mapa de puntos del fondo,

ParentRelative o None *I

La función XSetWindowBorder asigna al borde de la ventana el valor de punto especificado. La función XSetWindowBorder puede generar los errores BadMatch y Badwindow.

XSetWindowBorder(display, w, border-pixel) Display *display; /* Estructura de visualizaci6n * I Window w; /* ID de la ventana *I unsigned long border-pixel; I* Elemento del mapa de colores *I

La función XSetWindowBorderPixmap asigna el mapa de puntos especificado al borde de la ventana. Cuando se codifica el parámetro CopyFromParent, se usa el mapa de puntos del borde del padre. La función XSetWindowBorderPixmap, que se muestra a continuación, puede generar los errores BadMatch, BadPixrnap, y Badwindow.

XSetWindowBorderPixmap(display, w, border-pixmap) Display *display; I* Estructura de visualizaci6n */ Window w; I* ID de la ventana */ Pixmap border-pixmap; /* Mapa de puntos del borde o CopyFromParent */

La función XSetWindowColormap asigna el mapa de colores especificado a la ventana seleccionada. La función XSetWindowColormap, que se muestra a continuación, puede generar los errores Badcolor. BadMatch y BadWmdow.

XSetWindowColormap(display, w, colormap) Display *display; /* Estructura de visualizaci6n */ Window w; I* ID de la ventana *I Colormap colormap; /* Mapa de Colores*/

74

l_"__l_""". I_ "^ .." " _"_-


La función XDefineCursor define el cursor a utilizar en una ventana. Especificar el parámetro None es equivalente a ejecutar la función XUndefineCursor . La función XDefineCursor, que se muestra a continuación, puede generar los errores Badcursor y Badwindow.

XDefineCursor(display, w, cursor) Display *display; /* Estructura de visualizaci6n *I Window w; /* ID de la ventana */ Cursor cursor; /* Cursor a visualizar o None */

La función XUndefineCursor anula el efecto de la función XDefineCursor sobre la ventana en cuestión. Si el puntero esta en la ventana, se usará el cursor del padre. Si el puntero está en la ventana raíz, se volverá a usar el cursor por omisión. La función XUndefineCursor puede generar un error Badwindow.

XUnDefineCursor(display, w, cursor) Display *display; /* Estructura de visualizaci6n */ Window w; /* ID de la ventana */

L a función XConfzgure Window

La función XConfigureWindow mueve y redimensiona una ventana o cambia la anchura de su borde. Modificar la configuración de la ventana es similar a cambiar los atributos de la ventana mediante la función XChangeWindowAttributes. Para cambiar un valor de la configuración de ventana, utilice la orden OR sobre el bit de máscara apropiado de la siguiente lista, asigne el valor en la estructura de datos XWindowChanges, que mostramos a continuación, y llame a la función XConfigureWindow.

/* bits de la mhscara de valores de configuraci6n de ventanas *I

#define CWX (1 <<O) #define CWY (1 <<1) #define CWWidth (1 <et) #define CHeight (1<4) #define CWBorderWidth (1<< 4) #define CWSibling (1<< 5) #define CWStackMode ( N < 6)

I* Valores */ typedef struct {

int x, y; /* Posici6n de la esquina superior-izquierda exterior *I int width, height; /* Tamaflo interior d. l a ventana *I Int border-wldth; /* Anchura del borde en puntos */ Window sibling; /* ID de la ventana hermana para el apilamiento */

int stack-mode; /* Above, Below, TopIf, BottomIf, Opposite */ } XWindowChanges;

La función XConfigureWindow, que se muestra a continuación, utiliza los valores almacenados en la estructura XWindowChanges para reconfigurar el tamaño, posición, borde, y orden en la pila de una ventana.

XConfigureWindow(display, w, value-mask, values) Display *display; /* Estructura de visualizaci6n */ Window w; /* ID de la ventana */ unsigned int value-mask; /* MBscara para la estructura de valores */ XWindowChanges *values; /* Estructura XWindowChanges */

Cuando se especifica una hermana, stack-mode se interpreta como sigue:

75


Above La ventana se sitúa justo encima de la hermana. Below La ventana se sitúa justo debajo de la hermana. Toplf Si la hermana obstruye a la ventana, ésta se sitúa en la cima de l a

pila. Bottomlf Si la ventana obstruye a la hermana, dicha ventana se sitúa en

el fondo de la pila. Opposite Si la hermana obstruye a la ventana, ésta se sitúa en la cima

de la pila Si la ventana obstruye a la hermana, dicha ventana se sitúa al fondo de la pila.

Cuando no se especifica hermana, stack-mode se interpreta como sigue:

Above La ventana se sitúa en la cima de la pila. Below La ventana se sitúa en el fondo de la pila. Toplf Si alguna hermana obstruye a la ventana, la ventana se sitúa

en la cima de la pila. BottomIf Si la ventana obstruye a alguna hermana. dicha ventana se

sitúa al fondo de la pila. Opposite Si alguna hermana obstruye a la ventana, ésta se sitúa en la

cima de la pila. Si la ventana obstruye a alguna hermana, dicha ventana se sitúa en el fondo de la pila.

Si el bit de máscara banderín override-redirect de la ventana especificada esta en FALSE y otro cliente ha asignado la mascara de sucesos SubStructureMask a la ventana padre, el servidor generará un suceso ConfigureRequest, y no reconfigurará la ventana. En caso contrario la función XConfigureWindow generará sucesos ContigureNotify, GravityNotify, y Expose. La función XConfigureWindow puede generar los errores BadMatch, Badvalue, Badwindow.

Cambios de estado de la ventana y sucesos Expose

Entre los 33 tipos de sucesos declarados por X Window, 10 están asociados con los cambios de estado de las ventanas. En orden alfabético, estos sucesos son CirculateNotify, ContigureNotify, CreateNotify, DestroyNotify, GravityNotify, MapNotify, MappingNotify, ReparentNotify, UnmapNotify, y Visibi- 1ityNotify. Estrictamente hablando, los sucesos Expose no son sucesos de cambio de estado de la ventana sino sucesos de exposición de ventanas. Sin embargo, debido a que los sucesos Expose están estrechamente asociados con los sucesos de cambio de estado de la ventana, éstos se tratarán al final de esta sección.

El suceso CirculateNotijj

El suceso CirculateNotify informa a los clientes interesados de que una ventana ha cambiado su posición en la pila. Estos sucesos son generados por las funciones XCirculateSubWindows, XCirculateSubwindowsUp, y XCirculateSubwindowsDown. Para recibir el suceso CirculateiNotify, ha de seleccionar la máscara StructureNotifvMask para la propia ventana reordenada o SubstructureNotifyMask para la ventana padre. Dependiendo de la máscara seleccionada, el suceso de ventana será de la ventana reordenada o de su padre. La estructura de suceso XCirculateEvent es como sigue:


typedef struct { int type; unsigned long serial;

Bool send-event; Display *display; Window event; Window window; int place;

} XCirculateEvent;

/* CirculateNotify */ I* Número de la última petici6n procesada

por el servidor */ I* TRUE si la petici6n SendEvent *I I* Estructura de visualizaci6n *I I* Ventana del suceso *I /* Ventana reordenada */ /* PlaceOnTop, PlaceOnBotton */

El suceso ConfigureNotifi

El suceso ConfigureNotify informa a los clientes interesados de que una ventana ha cambiado de tamaño, posición, borde, o posición en el orden de apilamiento. Estos sucesos son generados por las funciones XConfigureWindow, XLowerWindow, XMapRaised, XMoveWindow, XMoveResizeWindow, XRaiseWindow, XResizeWindow, XRestackWindows, y XSetWindowBorderWidth. Para recibir el suceso ConfigureNotify ha de seleccionar la máscara StructureNotifyMask para la propia ventana récodigurada o SubstructureNotifyMask para la ventana padre. Dependiendo de la máscara seleccionada, el suceso de ventana será de la ventana reconfigurada o de su padre. Los clientes del gestor de ventana habitualmente ignoran las ventanas cuyo parámetro override-redirect tengan el valor TRUE. A continuación se muestra la estructura XConfigureEvent.

typedef struct { int type; I* DestroyNotify *I unsigned long serial; I* Número de la última petici6n procesada

por el servidor *I Bool send-event; /* TRUE si la petici6n SendEvent *I Display *display; /* Estructura de visualizaci6n */ Window event; /* Ventana del suceso */ Window window; /* Ventana reordenada *I int x,y; I* Posici6n de la ventana *I int width, height; /* Tamafio de la ventana */ int border-width; /* Anchura del borde *I Window above; I* Ventana hermana */ Boo1 override-redirect; /*Ignora la ventana si es TRUE */

} XConfigureEvent;

El suceso CreateNotifi

El suceso CreateNotify informa a los clientes interesados de que se crea una ventana. Estos sucesos son generados por las funciones XCreateWindow y XCreateSimpleWindow. Para recibir el suceso CreateNotify, ha de seleccionar la máscara SubstructureNotifyMask con el padre de la ventana a ser creada. Los clientes del castor de ventanas habitualmente ignoran las ventanas cuyo parámetro override-redirect tengan el valor TRUE. La estructura XCreateWindowEvent es como sigue:

typedef struct { int type; I* CreateNotify */ unsigned long serial; /* Número de la hltima petici6n procesada

Bool send-event; I* TRUE si la petici6n SendEvent */ Display *display; I* Estructura de visualizaci6n *I Window parent; I* Ventana padre */ Window window; /* ID de la ventana creada */

por el servidor */

77


int x,y; I* Posici6n de la ventana *I int width, height; I* Tamafio de la ventana *I int border-width; I* Anchura del borde *I Bool override-redirect; I* ignora la ventana si es TRUE *I

} XCreateWindowEvent;

El suceso DestroyNotifi

El suceso DestroyNotify informa a los clientes interesados de que se ha destruido una ventana. Estos sucesos son generados por las funciones XDestroyWindow y XDestroySubWindows. Para recibir el suceso DestroyNotify, ha de Seleccionar la máscara StructureNotifyMask para la propia ventana destruida o SubstructureNotifyMask para la ventana padre. Dependiendo de la máscara seleccionada, el suceso de ventana será de la ventana destruida o de su padre. Los clientes del gestor de ventanas habitualmente ignora las ventanas cuyo parámetro override-redirect tengan el valor TRUE. La estructura XDestroyWindowEvent es como esta:

typedef struct { int type; I* DestroyNotify *I unsigned long serial; I* Número de la última peticidn procesada

por el servidor */ Bool send-event; I* TRUE si la petici6n SendEvent *I Display *display; /* Estructura de visualizaci6n *I Window event; I* suceso de la ventana *I Window window; I* ID de la ventana destruida *I

} XDestroyWindowEvent;

El suceso GravityNotifi

El suceso GravityNotify informa a los clientes interesados de que una ventana se mueve debido a que su padre cambia de tamaño. Estos sucesos son generados por las funciones XConfigureWindow, XMoveresizeWindow y XResizeWindow. Para recibir el suceso GravityNotify, ha de seleccionar la máscara StructureNotifyMask para la ventana movida o SubstructureNotifyMask para la ventana padre. Dependiendo de la máscara selecionada, el suceso de ventana será de la ventana que se mueve o de su padre. A continuación se muestra la estructura XGravityEvent.

typedef struct { int type; /* GravityNotify */ unsigned long serial; I* Número de la última peticibn procesada

por el servidor *I Boo1 send-event; /* TRUE si la petici6n SendEvent *I Display *display; I* Estructura de visualizaci6n *I Window event; I* suceso de la ventana *I Window window; I* ID de la ventana destruida *I Boo1 override-redirect; /* Ignora la ventana si es TRUE *I

} XGravityEvent;

El suceso MapNotifi

El suceso MapNotify informa a los clientes interesados cuando se visualiza una ventana. Estos sucesos son generados por las funciones XMapWindow, XMapRaised, XMapSubwindows, y XReparentWindow. Para recibir el suceso MapNotify, ha de seleccionar la máscara StructureNotifyMask para la ventana que se visualiza o SubstructureNotifyMask para la ventana

78


padre. Dependiendo de la máscara seleccionada, el suceso de ventana será de la ventana que se visualizara o de su padre. Los clientes del gestor de ventanas habitualmente ignora las ventanas cuyo parámetro override-redirect tenga el valor TRUE. A continuación se muestra la estructura XMapEvent:

typedef struct { int type; I* MapNotify *I unsigned long serial; I* Número de la última petici6n procesada

Bool send-event; I* TRUE si la peticibn SendEvent *I Display *display; I* Estructura de visualizaci6n *I Window event; I* suceso de la ventana *I Window window; I* ID de la ventana destruida *I Boo1 override-redirect; I* Ignora la ventana si es TRUE *I

por el servidor *I

} XMapEvent;

El suceso MapppingNotifi

El suceso MappingNotify informa a todos los clientes de que algunas de las funciones XSetModifierMapping, XChangeKeyboardMapping, y XSetPointer termina sin error. A continuación se muestra la estructura XMappingEvent.

typedef struct { int type; I* MappingNotify *I unsigned long serial; I* Número de la última petici6n procesada por el servidor *I Bool send-event; I* TRUE si la petici6n SendEvent *I Display *display; I* Estructura de visualizaci6n *I Window window; I* No usado *I int request; I* MappingModifier, MappingKeyboard, o

int first-keycode; I* Primer c6digo de tecla *I int count; I* Número de c6digos de tecla modificados *I

MappingPointer *I

} XMapppingEvent;

El suceso ReparentNoti'

El suceso ReparentNotify informa a los clientes interesados de que una ventana cambia de padre. Estos sucesos son generados por la función XReparentWindow. Para recibir el suceso ReparentNotify, ha de seleccionar la máscara StructureNotifvMask para la ventana visualizada o SubstructureNotifyMask para la ventana padre antigua o nueva. Dependiendo de la máscara seleccionada, el suceso de ventana será de la ventana visualizada o de su padre antiguo o nuevo. Los clientes del gestor de ventanas habitualmente ignoran las ventanas cuyo parámetro override-redirect tiene el valor TRUE. A continua- ción se muestra la estructura XReparentEvent.

typedef struct { int type; I* ReparentNotify *I unsigned long serial; I* Número de la última petici6n procesada

Bool send-event; I* TRUE si la petici6n SendEvent *I Display *display; I* Estructura de visualizaci6n *I Window event; I* Ventana de suceso *I Window window; I* ID de la ventana que ha cambiado de padre *I int x,y; I* Posici6n de la ventana *I Boo1 override-redirect; I* Ignora la ventana si es TRUE *I

por el servidor *I

} XReparentEvent;

79


El suceso UnmapNotiih

El suceso UnmapNotify informa a los clientes interesados de que una ventana deja de estar visualizada. Estos sucesos son generados por las funciones UnmapWindow, y XUnmapSubwindows. Para recibir el suceso UnmapNotify, ha de seleccionar la máscara StructureNotifyMask para la ventana que deja de estar visualizada o SubstructureNotifyMask para la ventana padre. La estructura XUnmapEvent es como sigue:


Bool send-event; Display "display; Window event; Window window; Boo1 from-configure;

} XUnmapEvent;

I* UnmapNotify *I I* Número de la última petici6n procesada

I* TRUE si la petici6n SendEvent *I I* Estructura de visualizacibn *I I* Ventana de suceso *I I* ID de la ventana que deja de estar visualizada *I I* (ver debajo) *I

por el servidor *I

El suceso Visibility

El suceso Visibility informa a los clientes interesados de que ha cambiado la visibilidad de una ventana. Estos sucesos están asociados con los sucesos CirculateNotify, ConfigureNotify, GravityNotify, MapNotify, y UnmapNotify. A continuación se muestra la estructura XVisibilityEvent.


Bool send-event; Display *display; Window window; int x,y; int width, height; int count;

} XExposeEvent;

I* Expose *I I* Número de la última peticibn procesada

I* TRUE si la petici6n SendEvent *I I* Estructura de visualizacibn *I I* ID de la ventana expuesta *I I* Posici6n de la ventana *I I* Dimensiones de la ventana */ I* Sucesos Expose adicionales por llegar *I

por el servidor *I


Puntos clave

Principios básicos

Habitualmente, una ventana es un área rectangular de la pantalla, orientada en paralelo a los bordes de la pantalla. X Window prefiere definir las ventanas de la forma más amplia posible y permitir que los diseñadores de aplicaciones utilicen estos bloques de construcción como vean más conveniente. Un principio que ha guiado su diseño es el de “Proporcionar mecanismos en lugar de normas”.

Terminología básica de las ventanas

La ventana raíz cubre la pantalla completa y no se puede mover, redimensionar, ni destruir. La jerarquía de ventanas expresa la relación vertical entre ventanas. Las ventanas directamente subordinadas a otra ventana son sus hijas. Las ventanas que tienen el mismo padre son hermanas entre si. Se conocen como ascendientes al padre de una determinada ventana, al padre del padre, y así sucesivamente. Lo opuesto de ascendiente es descendiente o inferior. El orden de apilamiento describe la relación entre hermanas.

Visibilidad de las ventanas

A medida que se mueven o crean ventanas, áreas que eran anteriormente visibles pueden llegar a estar cubiertas u ocultas por otras ventanas. El contenido de la ventana puede estar cortado o limitado por su padre. Una ventana es visible solo si se cumplen las siguientes condiciones: ella y todos sus ascendientes están visualizadas, ninguna hermana la oculta, y no se encuentra recortada en su totalidad por un ascendiente.

Terminología sobre la geometría de las ventanas

La geometría de una ventana define su tamaño, forma, y posición dentro de su ventana padre. Los términos relativos a la geometría de las ventanas incluyen el origen, x, y, anchura, altura. y anchura del borde.

Características y atributos de las ventanas

A las características permanentes de una ventana se le conocen como características propias. Las características propias de una ventana se fijan en el momento de su creación. Entre éstas están la clase de ventana InputOup o InputOnly; la profundidad y el formato del valor del punto, conocido como uno visual. A las características de las ventanas que pueden cambiarse se les conoce como atributos. Entre ellos se incluyen el fondo y el borde de la ventana; la disposición de sus imágenes cuando el tamaño de la ventana cambia si hay algún mecanismo de almacenamiento para preservar el contenido de las ventanas cubiertas por otras ventanas y la forma en que las ventanas manejan los sucesos, mapas de colores, y cursores.

81


Ciclo de vida de las ventanas

Las principales etapas de la vida de una ventana son su creación, visualización y destrucción. Al crearse una ventana se define la relación de ésta con su padre e, implícitamente, con sus hermanas y se establecen su geometría, sus características y sus atributos. Para que la ventana llegue a ser visible es necesario visualizarla. La destrucción de la ventana la elimina y devuelve sus recursos al Sistema. Las funciones de configuración de ventanas modifican las características y geometría de éstas. Hay diez tipos de sucesos asociados a los cambios de estado de las ventanas.

Gestor de ventanas

Un gestor de ventanas es un cliente especial responsable de la manipulación de las ventanas en la pantalla. Los gestores de ventanas controlan la visualización de la pantalla; por ejemplo, determinan dónde se sitúan las ventanas de las aplicaciones y establecen el tamaño de éstas. Cada gestor de ventganas tiene su propia impronta visual.

82

Herramientas, conceptos y técnicas

Capítulo 5


En los capítulos anteriores se han introducido los conceptos básicos del sistema X Window y SU

programación a bajo nivel mediante llamadas a funciones Xlib. Aunque es esencial dominar las funciones Xlib, pocas aplicaciones X Window se programan usando sólo Xlib, por la sencilla razón de que existen herramientas más fáciles de usar. En este capítulo se presenta el segundo nivel de programación X Window, Xt Intrinsic, y la herramienta OSFMotif que es la extensión más usada de Xt Intrinsics.

El capítulo comienza con las ideas y terminología básicas, pasándose después a examinar la estructura tipica de una aplicación Motif. Esta estructura se utiliza con dos versiones del programa "Hola Mundo'' que se escribió con funciones Xlib en el Capítulo 2. E1 programa "Hola Mundo". A continuación se tratan con mayor detalle los conceptos y funciones necesarias para la correcta inicialización de la herramienta y la utilización efectiva de los widgets (elementos gráficos), recursos, y llamadas de retorno. Concluye con programas Motif más sofisticados.

Conceptos básicos

Con el conocimiento que ya tenemos del sistema X Window, es evidente que la programación con Xlib es bastante pesada. El programador debe crear, visualizar, coordinar, y destruir docenas de ventanas interrelacionadas y escribir cientos de líneas. Cada vez que una ventana se mueve o algo cambia su visibilidad, el programa debe plantearse el tener que guardar todo o parte de su contenido, X Window genera sucesos para indicar que se han producido acciones importantes. El programa debe estar listo en todo momento para aceptar los sucesos relevantes y procesarlos. Todo esto parece complicado, y lo es. La programación con Xlib no está hecha para los poco tenaces o los despistados.

La interfaz X Toolkit se situa entre el programador de aplicaciones y las llamadas a las funciones Xlib, permitiendo a los programadores dar órdenes a la computadora con un lenguaje de mas alto nivel que las llamadas de bajo nivel de Xlib. X Toolkit sustituye las ventanas y los sucesos por entidades más sofisticadas, widgets (elementos gráficos) y procedimientos de llamada de retorno. Por el momento, se pueden considerar los widgets como los bloques básicos con que se construye la interfaz gráfica de usuario, tales como menús y cuadros de diálogo. Los procedimientos de llamada de retorno informan a una aplicación de que el usuario ha referenciado un widget, quizás realizando una selección en un menú.

El X Toolkit consta de dos partes relacionadas. El Xt Intrinsics, que define una colección de funciones y estructuras de datos básicas, que son estándares para el sistema X Window y las herramientas en propiedad que amplían Xt Intrinsics ofreciendo unas herramientas más flexibles y que permitan una programación más potente. Cada herramienta en propiedad tiene una apariencia propia. Actualmente, las dos herramientas más comúnmente usadas son OSFMotif, asociada a marcas como IBM, HP, y DEC, y Open Look, asociada a Sun Microsystems y AT&T.

Dos categorías de programadores acceden a las herramientas de diferente forma. Los programadores de aplicaciones emplean los widgets que ya existen; según su modo de ver las cosas, un widget es una "caja negra". Los programadores de aplicaciones saben qué pueden defmir los widgets y como utilizarlos, pero

83


no conocen necesariamente lo que hay dentro del widget. Ya tienen bastantes cosas de las que ocuparse como para preocupares del comportamiento o composición interna de un widget.

Los programadores de widgets crean y venden widgets. Deben dominar los detalles internos de la creación y modificación de widgets. Idean widgets lo suficientemente flexibles como para satisfacer necesidades de lo más diversas. Lo programadores de widgets tienen un interés personal en mantener en secreto los detalles internos de sus widgets. A medida que aumenta el mercado X Window, se incrementa el número de programaciones de widgets cuyos productos se dirigen hacia aplicaciones especificas. Por ejemplo, es previsible un incremento en é1 numero de widgets de interés para los diseñadores de sistemas de información hospitalarios comercialmente disponibles.

Terminología básica

Este capítulo se basa en un amplio vocabulario técnico relativo a los widgets y las herramientas. A continuación se listan los términos clave.

Terminología relativa a los widgets y herramientas. Aplicación Programa construido con una herramienta

Procedimiento de llamada de retorno. También sé conoce como una llamada de retorno (callback). Una función dependiente de la aplicación llamada por una widget que requiere información de la aplicación.

Lista de llamadas de retorno (callback list) Una sene de funciones a ejecutar cuando se invoca un procedimiento de llamada de retorno.

Clase (Class) Un tipo de objeto. Una clase de objeto define las operaciones legales para ese objeto. Por ejemplo, la creación de widgets es una operación legal, mientras que su incorporación no lo es.

Jerarquía de clases (Calass hierarchy) La relación formal entre clases. Los objetos, por ejemplo widgets, más bajos en la jerarquía de clases, heredan operaciones de los objetos superiores en la jerarquía de clases.

Herencia (Inheritance) La capacidad de implementar operaciones especificas (métodos) de la superclase de los casos.

Caso (Instance) Una determinada ocurrencia de un objeto particular, por ejemplo un widget.

lntrinsics Nivel de programación X Window que define las funciones estándares y los tipos de datos utilizados en la creación de widgets y en la implementación de éstos en aplicaciones de usuario.

Método (Method) Un procedimiento que implementa una determinada operación soportada por la clase de los widgets.

Objeto (Object) Una unidad independiente que incluye los datos y las operaciones definidas para estos datos. Los widgets son los principales objetos que ofrece la herramienta.

Recurso (Resource) Un atributo del widget con nombre que puede ser asignado por el programador o, quizás, por el usuario. Los recursos de la herramientas son similares aunque distintos recursos de Xlib.

84


Subclase (Subclass) Una clase por debajo de (dentro de) otra clase en jerarquía de clases. Una subclase está más especializada de su superclase.

Superclase (superclass) Una clase por encima de otra clase en la jerarquía de clases. Una Superclase está menos especializada que sus subclases.

Widget Objeto básico de una herramienta. Entre los widgets más usados se incluyen las barras de desplazamiento, los menús dinámicos y los cuadros de diálogo.

Clases de widget Tipo de widget. La clase de widget define todos los atributos y operaciones disponibles para un grupo de widgets relacionados.

Aquellos que están familiarizados con los sistemas de programación orientada a objeto reconocerán muchos de los términos anteriormente citados, como por ejemplo clases, herencia, y caso (instance). Aunque el sistema X Window no esta basado en un lenguaje de programación orientado a objeto como Smalltalk o C++, utiliza sus principios en los widgets. A menudo los diseñadores de widgets no necesitan crear un nuevo widget a partir de la nada, sino que en su lugar modifican uno ya existente. El uso correcto de la programación orientada a objeto permite una mayor rapidez en el desarrollo y verificación de widgets.

Arbol de widgets

En el capítulo anterior se introdujo la jerarquía de ventanas La ventana raíz se encuentra en la cima de la jerarquía de ventana, siendo la ímica ventana que no tiene un padre. La ventana raíz puede tener varias hijas. La relación hijdpadre se fragua en la creación de la ventana, pero puede cambiarse mediante la función XReparentWindow. Recordemos que el contenido de una ventana hija nunca se puede ver fuera del contorno de su ventana padre. El árbol de widgets es similar a la jerarquía de ventanas.

La raíz del árbol de widgets se conoce como el widget de interfaz (Shell widget). La hnción de inicialización de la herramienta crea el Shell widget. Con la excepción de los menús dinámicos, el widget Shell es el padre de los otros widgets de la aplicación. El widget Shell interacciona con el gestor de ventanas, sirviendo a veces de intermediario entre éste y sus widgets hijos. Debido a que el widget Shell tiene superpuesto el widget principal de la aplicación, es invisible.

El nivel medio del árbol de widgets está compuesto por los widgets compuestos (Composite widgets) que reagrupan varios widgets hijos para formar la interfaz gráfica de usuario. Normalmente los widgets Composite no muestran datos por sí mismos. Cada clase de widget Composite implementa sus propias normas para la localización física de sus widgets hijos. Por ejemplo, los widgets Menú marcan que todos sus hijos tengan la misma anchura y alinean sus hijos verticalmente; si la aplicación requiere que un elemento del menú se vuelva más ancho, todos los elementos del menú se harán más anchos. Otras clases de widgets Composite tienen normas sobre su geometría menos estrictas. Por ejemplo, los widgets Box (cuadro) le permiten a la aplicación especificar el tamaño y la posición de los widgets hijos. Los widgets Pane reservan un espacio fijo para sus hijos y dejan que sean los usuarios quienes repartan este espacio entre éstos según quieran.

El tercero, y ultimo, nivel del árbol de widgets consta de widgets primitivos (Primitive widgets) que no tienen hijos. Ejemplos de widgets Primitive pueden ser los rótulos, los elementos de menú y los botones.

85


La clase de widgets de Intrinsics

Xt Intrinsics define cuatro clases de widgets básicos que son las superclases para todas las otras clases de widgets del sistema X Window. Esta clase de widgets de Intrinsics pasan características fimdamentales a la subclase de widgets de Intrinsics y a todas las clases de widgets de las herramientas. La Figura 5-1 muestra la relación entre las clases de widgets de Intrinsics. Se presentan comenzando por la cima de la jerarquía.

Core La clase widget Core (Núcleo) esta situada en la cima de la jerarquía. Juega un papel similar a la ventana raíz. Todos los widgets heredan recursos de esta clase. Sin embargo, ningún widget Core es útil, a menos que pertenezca a la clase Shell (Interfaz) o a una clase de widget de la herramienta. En términos técnicos, la clase de widgets Core es una metaclase (metaclass), una clase para organizar clases de widgets, no para organizar los propios widget,

Composite. La clase widget Composite (Compuesto) es una subclase de la clase Core. Los widgets pertenecientes a esta clase se llaman widgets Composite. Utilizando adecuadamente los widgets Composite incrementa la consistencia y coherencia de las aplicaciones. La clase de widget Composite es también una metaclase. Los widgets Composite se tratan con más detalle más adelante en este capítulo.

Q Composite

Figura 5-1. Clases de widgets de Intrinsics.

Constraint. La clase de widget Constraint (Restricción) es una subclase de la clase Composite. Los widgets pertenecientes a esta clase se llaman widgets Constraint (de restricción) Las clases widget Constraint gestionan sus hijos según una regla definida, o restricción. Por ejemplo, la clase de widget Menú obliga a que todos sus widgets se coloquen verticalmente y tengan la misma anchura. La clase de widget Constraint también es una métaclase.

Shell. La clase widget Shell (Interfaz) es una subclase de la clase widget Core que se restringe a un Único hijo. Los widgets pertenecientes a la clase widgets Shell (Sllell widgets o widgets de inter$az) suministran una interfaz entre el gestor de ventanas y los otros widgets de la aplicación. La clase de widget Shell no es una metaclase.

Las clases de widgets de la caja de herramientas

Las clases de widgets de la caja de herramientas son subclases de las clases de widgets de Intrinsics. Los widgets de la caja de herramientas actual se definen en parte según las reglas de las clases de widgets de

86


Xt Intrinsics, pero tienen además reglas y características propias, constituyendo uno de los principales elementos de las herramientas en propiedad. Muchas de éstas incluyen las siguientes clases de widgets de la caja de herramientas presentadas en orden.

Box (Cuadro). Un widget Box contiene otros widgets pero no especifica ninguna información de presentación. Es la propia aplicación la que especifica dicha información.

ButtonBox (Cuadro de botones). Un widget ButtonBox contiene otros widgets tales como botones O conmutadores, empaquetados para ocupar ordenadamente el espacio disponible.

Command (Orden). Un widget Command activa una determinada función cuando el usuario lo selecciona pulsando un botón del puntero, por ejemplo un botón del ratón. El widget Command es sinónimo del widget PushButton (Botón).

Confirm (Conjirmación). Un widget C o n f m es un widget dinámico que le pide al usuario que confirme una acción, como puede ser el borrar un archivo. En muchos casos, la aplicación detiene el procesamiento hasta que el usuario realiza la confiiación o cancelación.

Label (Rótulo). Un widget Label es un rotulo de texto que se visualiza sobre la pantalla y que no puede recibir entradas de usuario.

Menú. Un widget Menu contiene otros widgets tales como botones, colocados verticalmente y con una misma anchura.

MinMax. Un widget MinMax es similar a un widget Box, excepto en que la aplicación puede especificar unos tamaños mínimo y máximo.

PushButton (Botón). Un widget PushButton activa una determinada función cuando el usuario lo selecciona pulsando un botón de puntero, por ejemplo un botón del ratón. El widget PushButton es sinónimo del widget Command.

Scrollbar (Barra de desplazamiento). Un widget Scrollbar le permite al usuario seleccionar el área de datos visible en la pantalla.

TextField (Campo de texto). Un widget TextField recibe del usuario una cadena de texto.

Toggle (Conmutador). Un Toggle es un widget PushButton que asume primero un estado y después otro de los dos estados posibles, es similar a la tecla CAPSLOCK.

VerticalPane (División vertical). Un widget VerticalPane consta de varios hijos que se muestran formando una columna vertical, y a los que el usuario puede cambiar el espacio.

Interrelaciones entre clases de widgets

Si examinamos las anteriores clases de widgets, veremos que no son independientes. Por ejemplo, un widget Toggle (Conmutador) es una subclase (un tipo particular) del widget PushButton (Botón). Puede estar en sólo uno de dos estados posibles y cambia constantemente entre ellos. A su vez, un widget PushBumon (y por lo tanto, un widget Toggle) es un tipo particular del Widget Label (Rótulo). Ninguno de estos dos widgets se pueden usar para introducir texto. Por otro lado, debe quedar claro que un widget TextField (Campo de texto) no es un caso de widget Label (Rótulo), ya que su propio nombre muestra algo distinto a un rótulo (Label), que no permite entradas de usuario.

87


Cada operación disponible para una determinada clase de widgets se encuentra automáticamente disponible para sus subclases Muchas de las operaciones fundamentales de los widgets se definen una vez para la clase Core, siendo así aplicables a todos los widgets de X Window.

Cuando un programador define una nueva clase de widget, no comienza desde cero. Sólo necesita añadir declaraciones de datos especificas y el código necesario para terminar de definir la clase. Del resto ya dispone.

Convenios de nomenclatura de los widgets

El nombre del archivo de cabecera de una determinada clase de widgets es el nombre de la clase de widgets seguido por .h, con la restricción de que la longitud máxima del nombre del archivo de cabecera es de diez caracteres. Un subdirectorio de /usr/include/XII contiene normalmente los archivos de cabecera del conjunto de widgets.

En lenguaje C los nombres de los tipos con que se definen los casos de los widgets están compuestos por el nombre de la clase seguido por la cadena "Widget", por ejemplo, PushButtonWidget y ScrollingWidget. Las referencias externas a la estructura de clase de los widget se forman concatenando al nombre de la clase (esta vez sin ninguna letra mayúscula) la cadena "WidgetClass". Así, el archivo de cabecera incluiría los nombres pushbuttonWidgetClass y scrollingWidgetClass.

Visión general de los recursos de widgets

Recordemos del Capítulo 3, "Conceptos básicos y terminología", que Xlib define seis categorías de recursos que el servidor puede asignar a una determinada aplicación: ventanas, contextos gráficos, tipos de letra, cursores, mapas de colores, y mapas de puntos. Los recursos de herramientas son diferentes de los recursos del servidor, aunque ambos conceptos estén claramente relacionados. Un recurso de herramienta (toolkit resource) es un elemento de datos, requerido por el widget. En muchas aplicaciones, los usuarios podrán modificar los recursos de la herramienta según sus propias necesidades. De hecho una de las formas de asegurar el fracaso de una aplicación es el codificar de forma rigurosa todos los recursos de los widgets, forzando a los usuarios a hacer cosas a nuestro modo.

Los recursos de herramienta (a los que se va a llamar recursos en el resto de este capítulo) están asociados a un caso concreto de widget. Por ejemplo, a un menú PushButton (de botones) concreto se le asignan valores de recursos específicos, tales recursos son habitualmente compartidos con otros menús de PushButton, pero no siempre. La clase de widgets Core (Núcleo) es la raíz de la jerarquía de clases de widgets, así todos los widgets son miembros de la clase Core. Todos los recursos asociados a los widgets Core pertenecen a todos los widgets. La clase de widgets Composite (Compuestos) es una subclase de la clase Core (Núcleo). La clase de widget Composite (Compuestos) es una metaclase, lo que significa que las aplicaciones nunca crean widgets Composite como tales. Sin embargo, muchos widgets de la aplicación pertenecen a subclases de la clase de widgets Composite y heredan sus recursos.

A continuación en este capítulo se analiza la estructura de aplicación Motif y varios programas Motif operativos. Posteriormente se tratarán los recursos con mayor detalle.

Estructura de una aplicación Motif

Para crear una aplicación Motif, seguiremos los siguientes pasos:

88


~ ~~~~~ ~ ~ ~

1. Incluir el archivo de cabecera estándar de Motif < Xm/Xm.h >

2. Incluir el archivo de cabecera público para cada clase de widget que se usa. Los archivos de cabecera privados se utilizan sólo para construir widgets, no para utilizarlos.

3. Inicializar la herramienta usando las funciones XtAppInitialize o XtVaAppInitialize.

4. Crear los widgets usando la función XtVaCreateManagedWidget una vez para cada widget.

5. Registrar las llamadas de retorno, acciones, y gestores de sucesos necesarios.

6 . Activar los widgets mediante una única llamada a la función XtRealizeWidget. Este proceso crea las ventanas y las visualiza a continuación sobre la pantalla.

7. Llamar a la función XtAppMainLoop para iniciar el bucle de procesamiento.

Examinemos cada uno de estos pasos tomando como ejemplo una aplicación familiar, el programa "Hola Mundo". El primero de los ejemplos incluya sólo seis de los siete pasos.

Ejemplo 1: Revisión del programa Hola Mundo

La primera versión Motif del programa Hola Mundo es similar a la versión Xlib presentada en el Capítulo 2, "El programa Hola Mundo", sigue la estructura general de las aplicaciones Motif con la única excepción de que, por simplicidad, se salta el paso 5. Este programa no registra ninguna llamada de retorno, acción. o gestor de sucesos.

Paso I : Incluir el archivo de cabecera de Motif

El archivo de cabecera de Motif contiene las definiciones de datos necesarias para el procesamiento de las aplicaciones Motif. Para incluir este archivo de código, se ha de escribir una única línea:

#include <Xm/Xm.h>

Paso 2: Incluir un archivo de cabecera público

X Window proporciona un archivo de cabecera público (public headerjle), disponible en un directorio predefinido. El nombre del archivo es el de la clase de widgets con las iniciales en mayúsculas y un máximo de diez caracteres, en este caso, Labe1.h. Los archivos de cabecera públicos contienen la siguiente información:

Directivas para impedir que el preprocesador incluya los archwos de cabecera publicas más de una vez.

0 Una directiva include para la superclase de la clase particular.

0 Definiciones para los nombres de esta clase widgets, clases, y tipos de recursos, si estas definiciones no están en el archivo de cabecera < XI1 / StringDefs.h >.

0 Tipos de datos requeridos para los recursos asociados con este widget.

0 Una referencia externa al puntero de registro de clase de esta clase que apunta al registro de clase declarado en el archivo de cabecera privado asociado.

89


El tipo de cabecera privada es sólo de interés para los programadores de widgets. Es considerablemente mas complicada que el tipo de cabecera pública.

En este programa concreto sólo se utiliza una línea de código para especificar el archivo de cabecera público que se requiere, como se muestra a continuación.

#include <Xm/Label.h>

Paso 3: Inicializar elprograma y la caja de herramientas

Este paso consta de dos partes: la inicialización del programa y la de la propia caja de herramientas.

Inicialización del programa

La inicialización de un programa Motif es una operación bastante directa. Las tres primeras instrucciones son estándares para los programas en lenguaje C. Un contexto de aplicación (application context) es un puntero a una estructura de datos que contiene los datos asignados por la caja de herramientas para la aplicación. Es obligatorio especificar al menos un contexto de aplicación para cada aplicación (pocas aplicaciones especifican más de un contexto de aplicación). En este programa se declaran dos nombres de widgets, ordenados según la jerarquía de widgets.

main (argc, argv) int argc; char *argv[);

XtAppContext app-context; /* Especifica una conexi6n con el servidor */ Widget theparent, hellow; /* Identifica los widgets */

{

Inicialización de la caja de herramientas

La inicialización de la caja de herramientas es más complicada que la del programa La función XtAppInitialize establece una conexión con el servidor y crea un widget Shell (Interfaz), en este caso llamado theparent. A continuación la función lee en la base de datos de recursos para obtener cualquier argumento de la línea de órdenes disponible y que anule otras especificaciones de recursos. Aunque la función XtVaAppInitialize tiene ocho parámetros, este programa usa solo dos de ellos.

theparent = XtVaAppInitialie( &app-context, /* Contexto de aplicaci6n */ “XExample”, /* Clase de aplicaci6n */ NULL, O, I* Lista de opciones de la Unea de ordenes */ &argc, argv, /* Argumentos de la linea de ordenes */ NULL, /* Ausente el archivo por omisi6n de la

aplicaci6n */ NULL); /* Termina la lista de argumentos variables */

El primer argumento de la función XtVaAppInitialize pasa la dirección del contexto de la aplicación, accediendo a una estructura de datos que contiene datos relevantes asociados con la aplicación.

El segundo argumento identifica el nombre de la clase de aplicación. Aquí, el nombre de la clase es el mismo que el nombre de la aplicación, excepto que la primera letra del nombre de la clase está escrita en mayúscula. Si la primera letra es una x, la segunda letra se escribe también en letra mayúscula

La función XtVaAppInitialize devuelve el nombre del widget Shell (Interfaz), el padre del primer widget creado por la aplicación. En este ejemplo, el widget Shell se llama theparent.

90


Paso 4: Creación y gestión de los widgets

Es en este paso cuando se crean los widgets y se informa de ello a sus padres. Esto se lleva á cabo con el siguiente segmento de código.

hellow = XtVaCreateManagedWidget( "hellow" I* Nombre del widget *I xmlabelwidgetClass, /* Clase de widget del archivo de. cabecera *I

theparent, NULL)

I* Widget padre *I /* Termina la lista de. argumentos variables *I

La función XtVaCreateManagedWidget crea el widget hellow, cuya clase de widget es Label (el segundo argumento lo especifica así ya que su valor es XmlabelWidgetClass). El tercer parámetro especifica el widget padre, creado en el paso anterior. Un widget gestionado (managed widget) es un widget cuya geometría es gestionada por el widget padre. El widget padre asigna espacio solo a sus hijos gestionados. El widget hellow es un widget gestionado.

Paso 5: Registrar llamadas de retorno, acciones, y gestores de sucesos

Este sencillo programa no registra las llamadas de retorno, acciones, o gestores de sucesos. Se ha aplazado hasta la versión 2 de este ejercicio, que incluirá este paso.

Paso 6: Activación de los widgets

Activar (Realzing) los widgets supone el crearlos de hecho (casos concretos) y visualizar a continuación sus ventanas. Esto se hace con una ímica finción:

XtRealiieWidget(theParent);

Esta función negocia con el gestor de ventanas la colocación de la ventana resultante, además de visualizarla, lo cual, como en el caso de las funciones Xilb, se debe hacer antes de que las ventanas lleguen a ser visibles.

Paso 7: Bucle de sucesos

Los programas de Xlib y de la caja de herramientas son controlados mediante sucesos. Sin embargo, los programadores de Xlib están forzados a codificar sus propias rutinas de gestión de sucesos, mientras que la propia herramienta se encarga de toda (o parte) de la gestión de sucesos. Este ejemplo concreto es bastante simple debido a que el programa no responde a los sucesos del usuario.

XtAppMainLoop(app-context);

Ya está completa la primera versión del programa Hola Mundo de OSFiMotif, excepto en que no registra ninguna llamada de retorno, acción, o gestión de sucesos. En la próxima versión se solucionará esta situación.

I* Paso 1 Archivo de cabecera Motif *I #include <Xm/Xm.h>

I* Paso 2 Archivo de cabecera público para las clases de widgets usados *I #include <Xm&abel.h>

I* Paso 3 lnicializar el Programa y la Herramienta *I main (argc, argv)

91


int argc; char *argv[];

XtAppContext app-context; I* Especifica una conexien con el servidor *I Widget theparent, hellow; /* Identifica los widgets */

{

theparant = XtVaAppInitialize( ¿Lapp-context, I* Contexto de aplicacibn */ "XExamplel", I* Clase de aplicacibn *I NULL, O, I* Lista de opciones de la linea de ordenes *I &argc, argv, I* Argumentos de la linea de ordenes */ NULL, I* Ausente el archivo por omisi6n de la aplicacien *I NULL); I* Termina la lista de argumentos variables */

/* Paso 4 Creacien y gesti6n de widgets *I hellow = XtVaCreateManagedwidget( "hellow", /* Hombre del widget */ XmLabelWidgatClass, I* Clase de widget del archivo de cabecera *I theparent, I* Widget padre */

NULL); /* Termina la lista de argumentos variables */

I* Paso 5 Ausente de este programa de ejemplo */

I* Paso 6 Activar los widgets */ XtRealizeWidget(theParent);

I* Paso 7 Bucle de Sucesos *I XtAppMainLoop(app-context); I

El resultado de la ejecución de este programa se muestra en la Figura 5-2.

El programa Motif no muestra la Cadena de caracteres "hola-mundo" como en el Capítulo 2, "El programa Hola Mundo". Para que aparezca esta cadena, se ha de sustituir por las siguientes dos ultimas líneas de las ESPECIFICACIONES DE RECURSOS DEL EJEMPLO 1 :

*hellow.labelstring: hola-mundo

El archivo MAKE que viene a continuación se usó para procesar este programa en SCO Open Desktop. Para otras implementaciones de X Window es distinto.

RM = rm -f cc = cc CFLAGS = -0 INCLUDE = -Uusr/include -I/usr/include/XII LIBS = -1Xm -lXt 4x1 1 -1socket -1malloc -IPW

$(RM) $63 .c.o:

%(CC) -c $(CFLAGS) $INCLUDE) %*.c all: ejemplol ejemplol: ejemplo1.o

%(CC) "o $(CFLAGS) ejemplo1.o $(LIBS) @echo Terminada la ejecucibn de I archivo de construcci6n del ejemplo 1

$@M) $63


Ejemplo 2: Revisión del programa Hola Mundo

La segunda versión Motif del programa Hola Mundo es similar a la versión presentada anteriormente con una única excepción: este programa registra una llamada de retorno única. Por simplicidad, en lo que sigue sólo haremos referencia a los pasos que han cambiado. Sin embargo, para facilitar el trabajo se ofrece el listado completo.

Figura 5-2. Primer programa Motif sin llamadas de retorno.

Paso 2: Incluir un archivo de cabecera público

El paso 2 consta ahora de dos líneas: se requiere un segundo archivo de cabecera público ya que este programa incorpora ahora tal widget PushButton. asociado con la fimción de llamada de retorno.

#include <Xm.Label.h> #include <Xm.PushB.h>

Paso 3: Inicializar el programa y la caja de herramientas

El paso 3 incluye ahora una función de llamada de retorno de botón Exit (Salida). La función de llamada de retorno Exit tiene un prototipo que acepta tres argumentos:

0 El primer argumento, awidget, es el widget que activa la llamada de retorno. El widget se especifica aquí formalmente y es el primer argumento en la función de llamada de retorno XtAddCallback.

El segundo argumento, client-data, es el valor pasado como último argumento a la función de llamada de retorno XtAddCallback.

El tercer argumento, call-data, es un elemento de datos que pasa el widget, dependiendo de la clase de widget. Si un widget no genera ninguno, pasa O como tercer parámetro.

Nota Es una práctica estándar escribir en letra mayúscula la primera letra de una función de llamada de retorno para distinguirla del widget asociado.

El resto del código del paso 3 no cambia, por lo que no aparece aquí.

void Exit(awidget, client-data, call-data) Widget awidget; XtPointer client-data, call-data;

93


Paso 5: Registrar llamadas de retorno, acciones y gestores de sucesos

Por el momento el programa sólo registra a Exit como h c i ó n de llamada de retorno del widget Pushbutton. El primer argumento, hellow, es el widget que desencadena la llamada de retorno. El segundo argumento, XmNactivateCallback es una constante simbólica que identifica qué recursos de llamada de retorno se establecen. El tercer argumento es la función que el widget llamará.

El cuarto argumento es el dato que se pasará a esa fimción, en este caso no se pasa nada

XtAddCallBack(hellow, XmNactivateCallback, Exit, O);

El resto del programa es exactamente lo mismo que el programa anterior. La diferencia principal entre los dos programas es la adición de una función de llamada de retorno que genera código adicional en varios lugares del programa.

I* Paso 1 Archivo de cabecera Motif como antes */ #include cXm/Xm.h>

I* Paso 2 Archivo de cabecera pdblico para las clases de widgets usadas *I I* Incluye un archivo adicional para el widget PushButton *I #include cXm/XLabel.h> #include <Xm/PushB.h>

I* Paso 3 Inicializar el programa y la herramienta *I I* Funci6n de llamada de retorno adicional del b o t h de Salida *I void Exit(awidget, client-data, call-data) Widget awidget; {

1

main (argc, argv) int argc; char *argv[]; XtAppContext app-context; Widget theparent, hellow;

theparent = XtVaAppInitialize{

exit(0);

&app-context, “XExamplet”, NULL, O, &argc, argv, NULL, NULL);

I* Especifica una conexi6n con el servidor *I I* Identifica los widgets *I

I* Contexto de la aplicaci6n */ I* Clase de aplicaci6n *I I* Lista de opciones de la linea de ordenes */ I* Argumentos de la línea de ordenes *I I* Ausente el archivo por omisi6n de la aplicaci6n *I I* Termina la lista de argumentos variable *I

I* Paso 4 Creaci6n y gesti6n de los widgets *I I* El widget es ahora de la clase Pushbutton *I hellow = XtVaCreateManageWidget(

“ghellow”, /* Nombre del widget *I xmPushButtonClass, I* Clase de widget del archivo de cabecera *I theparent, I* Widget padre *I NULL); I* Termina la lista de argumentos variables *I

I* Paso 5 Ahora estP presente una funcidn de llamada de retorno *I XtAddCallback(hellow, XmNactivateCallback, Exit, O);

I* Paso 6 Activar los widgets *I XtRealizeWidget(theParent);

I* Paso 7 Bucle de sucesos *I

94

Herramientas, conceptos y tdcnicas

XtAppMainLoop(app-context); 1

El resultado de la ejecución de este programa se muestra en la Figura 5-3. Para modificar la salida de este programa se ha de modificar las ESPECIFICACIONES DE RECURSOS DEL EJEMPLO 2, como ya se vio con el ejemplo l .

El archivo MAKE que viene a continuación se usó para procesar este programa en SCO Open Desktop. Para otras implementaciones de X Window es distinto.

RM=rm-f cc = cc CFLAGS = -0 INCLUDES = -Yusr/include -Uusr/include/Xll LIBS = -lXm -lXt 4x11 -1socket -1malloc -1PW .c.o: $(M) S@ %(CC) -C %(CFLAGS) $(INCLUDES) $*.c all:: ejemplo2.0

$(CC) -o $@ %(CFALGS) ejemplo2.0 $(LIBS) @ echo Terminada la ejecuci6n del archivo de construcci6n del ejemplo 2

$@M) S@

Figura 5-3. Primer pantalla Motif con llamadas de retorno.

Inicialización de la caja de herramientas y funciones relacionadas

Ahora que hemos visto en acción dos versiones del programa Hola Mundo usando una caja de herramientas, es el momento de explorar con mayor profundidad algunos de los conceptos y funciones introducidos en estos programas. Se verán funciones alternativas m á s sofisticadas que nos permiten construir programas más potentes basados en la caja de herramientas.

Inicialización por omisión

Los dos programas "Hola Mundo" usaban la función XtVaAppInitialize de Intrinsics. Esta función y la función asociada XtAppInitialize llaman a cuatro funciones Intrinsics en el siguiente orden: XtToolkitInitialize, XtCreateApplicationContext, XtOpenDisplay, y XtAppCreateShell. Las funciones XtVaAppInitialize y XtAppInitialize difieren en el modo en que especifican los parámetros.

95


Ambas llaman a la función XtOpenDisplay con los parámetros display-string display-string y application-string puestos a NULL. Además, ambas llaman a la función XtAppCreateShell con el parámetro application-name puesto a NULL y establecen la clase de widget como applicationShellWidgetClass. La función XtAppInitialize es como sigue:

Widget XtAppInitialie(app-context-return, application-class, options, num-options, argc-in-out, argv-in-out, fallback-resource, args, num-args)

XtAppContext *app-context-return; String application-calss; XrmOptionDescList options; Cardinal num-options; Cardinal *argc-in-out; String *argv_in-out; String *fallback-resources;

ArgList args;

Cardinal num-args;

/* Si no es NULL, devuelve el contexto de la aplicaci6n */ /* Especifica el nombre de clase de la aplicacibn */ /* Especifica la tabla de opciones de la linea de ordenes */ /* Número de entradas en la tabla de opciones */ /* Puntero al número de argumentos de la linea de ordenes */ /* Puntero a los argumentos de la linea de ordenes */ /* Valores de recursos a usar, si el archivo de recursos

/* Lista de argumentos para los recursos del widget

/* Número de entradas en la linea de argumentos */

de la clase de aplicaci6n no esta disponible */

Shell creado *I

La función XtVaAppInitialize se muestra a continuación.

Widget XtVaAppInitializa(app-context_Ieturn, application-class, options, nun-options, argc-in-out, argv-in-out, fallback-resource, . . .)

XtAppContext *app-context-return; I* Si no es NULL, devuelve el contexto

String application-class; I* Especifica el nombre de la clase de la aplicación */ XrmOptionDescRec options[]; I* Especifica la tabla de opciones de la línea de ordenes *I Cardinal nun-options; I* Número de entradas en la tabla de opciones *I Cardinal *argc-h-out; /* Puntero al número de argumentos de la línea de ordenes */ String *argv-ir-out; I* Puntero a los argumentos de la línea de ordenes *I String *fallback-resources; /* Valores de los recursos a usar, si el archivo de

de la aplicación *I

recursos de la clase de aplicación no está disponible */

/* Lista variable de argumentos para anular otras especificaciones de recursos del interfaz *I

Las funciones XtVaAppInitialize y XtAppInitialize son similares.

Inicialización de los elementos internos de la caja de herramientas

La función XtToolkitInitialize inicializa Intrinsics. Crea los contextos de aplicación, establece las conexiones de visualización, y crea los widgets Shell (Interfaz). Sin duda es más fácil para los programadores escribir una única orden de inicialización que tener que utilizar varias hc iones de inicialización, como requiere Xlib.

Las funciones XtVaAppIninalize y XtAppInitialize llaman automáticamente a la h c i ó n XtToolkitInitialize. Esta función no se debe de llamar más de una vez en ningún programa de X Window.

96


Manejo del contexto de la aplicación

El contexto de la aplicación XtAppContext es opaco (opaque), ya que los clientes no pueden leerlo. Recordemos que un contexto de aplicación, en esencia, especifica una conexión con el servidor. Podemos crear un contexto de aplicación llamando a la función XtCreateApplicationContext, que devolverá dicho contexto de la aplicación. de la siguiente forma:

XtAppContext = XtCreateAppticationContextO

Las funciones XtVaAppInitialize y XtAppInitialize llaman automáticamente a esta función.

La función XtWidgetToApplicationContext determina el contexto de aplicación asociado con un determinado widget. Se codifica como sigue:

XtAppContext XtWidgetToApplicationContext(w) Widget w; I* Especifica el widget cuyo contexto de aplicaci6n se requiere *I

Nota. El widget requerido debe ser de la clase Object o de una subclase de dicha clase.

La función XtDestroyApplicationContext, que mostramos a continuación, elimina el contexto de aplicación seleccionado, pero no antes de completar el procedimiento de llamada de retorno u otra acción que haya llamado a la función.

void XtDestroyApplicationContext(app-context) XtAppcontext app-context; /* Especifica el contexto de aplicaci6n */

Manejo de la visualizacidn

La función XtOpenDisplay establece la conexión de visualización, inicializándola, y la incluye en el contexto de aplicación especificado mediante una llamada a la función XtDisplaylnitialize. La función XtOpenDisplay, que mostramos a continuación, es llamada automáticamente por las funciones XtVaAppInitialize y XtAppInitialize.

Display *XtOpenDisplay(app-context, display-string, application-name, application-calss, options, cum-options, argc, argv)

XtAppContext app-context; I* Especifica el contexto de la aplicaci6n */ String display-string; I* Cadena de visualizaci6n o NULL */ String application-name; /* Nombre del caso de la aplicaci6n,

String application-class; /* Clase de aplicacidn */ XrmOptionDescRec options; /* Especifica el anilisis gramatical de la linea

Cardinal num-options; /* Número de entradas en la lista de opciones */ Cardinal*argc; /* Puntero al número de argumentos de la linea de ordenes */ String *argv; /* Parimetros de la linea de ordenes */

habitualmente NULL */

de ordenes para los recursos *I

La cadena de visualización (display-string) especificada depende del sistema. Los sistemas UNIX usan el formato hostname:display-number:screen-number. Los valores por omisión se corresponden con la computadora central actual y la pantalla especificada por el servidor.

La función XtOpenDisplay determina el nombre de la aplicación comprobando en orden las siguientes condiciones:

97


0 Un campo de la línea de órdenes dado por el parámetro argv, compuesto por el nombre de la aplicación seguido por -name en el caso de que se haya dado una orden.

0 El nombre de la aplicación se encuentra en el parámetro application-name siempre que el parámetro no sea NULL.

El nombre de la aplicación es el valor de la variable de entorno RESOURCE-NAME, si se da valor a esta variable.

0 El nombre de la aplicación se deriva del nombre usado al llamar al programa situado en argv[0] si este valor no es NULL. Todos los directorios y componentes de tipo de archivo se deben eliminar.

0 Si no se cumple ninguna de las condiciones anteriores, el nombre de la aplicación es "main".

La función XtDisplaylInitialize sitúa realmente la información de visualización en el contexto de la aplicación. Esta función debe ser llamada implícitamente o explícitamente antes de crear ningún widget para esta visualización concreta. Habitualmente la función XtDisplaylnitialize es llamada por la función XtOpenDisplay. La única diferencia entre estas dos funciones es que la función XtDisplayInitialize, que se muestra a continuación, usa el parámetro *dispZay-string, mientras que la función XtOpenDisplay usa el parámetro *display.

Display *XtDisplayInitialize(app-context, display-string, application-name, application-class, options, num-options, argc, argv)

XtAppContext app-context; Display *display-string; String application-name; String application-class; XrmOptionDescRec options;

Cardinal num-options; Cardinal *argc; String *argv;

I* Especifica el contexto de aplicaci6n *I /* Visualizacibn a inicializar *I I* Nombre de la aplicacibn, habitualmente NULL */ I* Clase de aplicaci6n *I /* Especifica el analisis gramatical de la linea de ordenes

para los recursos *I I* Número de entradas en la lista de opciones */ I* Puntero al número de argumentos de la línea de ordenes *I I* Parametros de la Unea de ordenes *I

Creación del widget Shell (de interfaz) inicial

La función XtAppCreateShell crea un widget Shell, una de cuyas clases es applicationShellWidgetClass, la clase del widget de raíz que se encuentra en la cima de todas las jerarquías de widgets. Todas las aplicaciones con widgets deben tener un widget Shell y por eso se debe llamar explícitamente o implícitamente a esta función. El widget applicationshell se puede crear llamando a las funciones XtVaAppInitialize o XtAppInitialize. La función XtAppCreateShell tiene la siguiente forma:

Widget XtAppCreateShell(app1ication-name, application-class, widget-class, display, args, num-args)

String application-name; I* Nombre de la aplicaci6n, habitualmente NULL *I String application-class; I* Clase de la aplicaci6n *I Widgetclass widget-class; I* Clase de widget del widget de nivel superior *I Display *display; I* Recursos de visualizacibn suministrados *I ArgList args; I* Lista de argumentos para los recursos creados

Cardinal num-args; I* Número de entradas en la lista de argumentos *I por el widget interfaz *I

98


Nota. Los parámetros application-name v application-class de la función XtDisplaylnitialize deben ser los mismos que los parámetros correspondientes de la función XtAppCreateShell. La forma más fácil de asegurar esta correspondencia es usar las funciones XtVaAppInitialize o XtAppInitialize para inicializar la aplicación.

Salida de las aplicaciones Hay varias formas de salir de un programa X Window. El modo más simple es a través de un procedimiento del sistema operativo, como por ejemplo el procedimiento exit de UNIX. Este procedimiento libera los recursos del cliente asociados a la aplicación y deshace la conexión con el servidor X. El servidor libera todos sus recursos asociados con la aplicación, incluyendo las ventanas.

Algunas veces un programa debe continuar procesándose después de cancelar su visualización. En este caso, debemos usar las funciones XtDestroyApplicationContext o XtCloseDisplay.

void XtDestroyApplicationContext(app-context) XtAppContext app-context; I * Especifica el contexto de aplicacidn a destruir */

La función XtDestroyApplicationContext puede ser llamada desde cualquier lugar de la aplicación. Esta función cierra todas las visualizaciones en el contexto de aplicación y se asegura de que se envían al servidor todas las peticiones almacenadas antes de romper el enlace con él. El contexto de aplicación se destruye sólo cuando se han procesado todos los sucesos relevantes.

La función XtCloseDisplay cierra una visualización pero no destruye el contexto de aplicación. También se asegura que se envíen al servidor todas las peticiones almacenadas antes de romper el enlace con él.

void XtCloseDisplay(disp1ay) Display *display; /* Especifica la visualizacidn a cerrar */

Nota. Antes de usar las funciones XtCloseDisplay o XtDestroyApplicationContext, debemos llamar a la función XtDestroyWidget para destruir el widget Shell de nivel superior asociado con la visualización. En caso contrario, la estructura de datos del widget permanecerá en el programa de aplicación sin la menor utilidad.

La hnción XtDestroyWidget, que se muestra a continuación, destruye el widget especificado y todos sus hijos.

void XtDestroyWidget(w) Widget w; /* Especifica el widget a destruir */

Esta función destruye también la ventana del widget. El proceso de destrucción del widget implica dos pasos, pero éstos son transparentes para los programadores de aplicaciones.

Widgets Los widgets Constituyen el núcleo de Intrinsics y de la herramienta Motif. Ahora que hemos visto como funcionan los widgets en los programas Motif, es el momento de analizarlos con mayor profundidad. Inicialmente, en esta sección se introduce el ciclo de vida del widget; pasando a continuación a examinarse un tipo particular de widget, el widget Shell (Interfaz). En la próxima sección, "Recursos", se estudian los widgets Core (del núcleo) y Composite (Compuestos), y sus recursos.

99


Cc'clo de vida del widget

Recordemos del Capítulo 4, "Ventanas y técnicas de trabajo con ventanas", que el ciclo de vida de la ventana incluye su creación, visualización y cancelación de esta, y su destrucción. El ciclo de vida del widget es similar incluyendo la creación, activación, visualización y cancelación de ésta, y destrucción del widget. El proceso completo de creación del widget consta de las siguientes actividades

0 Se ha de reservar espacio y asignar recursos a los widgets. Estos widgets se pueden incluir o no en el grupo de widgets gestionados por sus padres. Este paso supone llamar a la función XtCreateWidget y optativamente a la función XtManageChild.

0 Se informa a los widgets Composite de la gestión de sus hijos. Este proceso comienza desde el fondo del árbol de widgets y sube hacia arriba. Dependiendo del espacio disponible, un widget padre puede cambiar completa o parcialmente el tamaño y posición de sus hijos. También puede negociar con su propio padre la obtención de más espacio en la pantalla.

La función XtRealizeWidget crea y visualiza las ventanas partiendo de la cima y bajando en el árbol de widgets. A continuación visualiza todos los widgets gestionados.

Creación de widgets

La función XtCreateWidget crea un caso (instance) del widget. Entre sus actividades están las siguientes:

Determinar si han sido inicializadas la clase y la superclase del widget e inicializarlas si es necesario.

Asignar memoria para el caso (instance) del widget.

Asignar memoria para las restricciones (constraints) del padre, si las hay.

Inicializar los campos de los recursos.

Inicializar el widget.

0 Situar el widget en la lista de hijos de su padre, si el padre es un widget Composite.

Inicializar las restricciones del padre, si el padre es un widget Constraint (Restricción).

Estas actividades son transparentes para el programador de la aplicación.

Widget XtCreateWidget (name, objet-class, parent, args, num-args)

String name; /* Especifica el nombre de caso del recursos para el widget creado */ Widgetclass object-class; /* Puntero a la clase de widget para el objeto creado *I Widget parent; I* Widget padre */ ArgList; /* Lista de argumentos anulando todas las otras

Cardinal num-args; I* NQmero de entradas en la lista de argumentos */ especificaciones de recursos */

Los argumentos de XtCreateWidget tienen varias restricciones. El argumento name (nombre) debe ser diferente de los nombres de los casos de recursos de todos sus hermanos. El parámetro object-class (clase de objeto) debe ser de la clase objectclass o de una de sus subclases. El argumento parenf (padre) debe ser de la clase Object o de una de sus subclases.


La función XtVaCreateWidget es similar a la función XtCreateWidget, salvo en que los parámetros args y num-args son sustituidos por una lista varargs (variable de argumentos).

La función XtCreateManagedWidget, que se ofrece a continuación, crea widgets gestionados por sus padres. Es una útil función que llama a la función XtCreateWidget y después a XtManageChild.

Widget XcreateManagedWidget (name, widget-class, parent, args, num-args)

String name; I* Especifica el nombre del caso del recurso para el widget creado *I

Widgetclass widget-class; I* Puntero a la clase de widget para el objeto creado *I Widget parent; I* Widget padre *I ArgList args; I* Lista de argumentos anulando todas las

Cardinal num-args; I* Número de entradas en la lista de argumentos *I otras especificaciones de recursos *I

Los argumentos de XtCreateManagedWidget tienen varias restricciones. El parámetro widget-class debe ser de la clase rectObjClass o de una de sus subclases. El argumento parent debe ser de la clase Composite o de una de sus subclases.

La función XtVaCreateManagedWidget es similar a la función XtCreateManagedWidget, salvo en que los parámetros args y num-args son sustituidos por una lista variable de argumentos.

Activación de los widgets

La fknción XtRealizeWidget activa (crea y visualiza una ventana para) un caso de un widget. Entre sus actividades están las siguientes:

Llamar a un procedimiento para gobernar los hijos gestionados por todos los widgets Composite (Compuestos) desde abajo hacia arriba dentro del árbol de widgets.

Crear una estructura de datos XSetWindowAttributes y llenarla con información procedente de los campos del widget Core.

Incorporar la información relativa al widget a la estructura de datos SetWindowAttributes, activando el widget, y creando la ventana.

Activar los hijos gestionados por los widgets Composite (Compuestos), visualizando sus ventanas si el parámetro lógico mapped-when-managed es TRUE.

La función XtRealizeWidget es como sigue:

void XtRealizeWidget(w) Widget w; I* Especifica el widget *I

El widget especificado debe ser de la clase Core o de algún subconjunto de esa clase. Las actividades de la lista anterior son transparentes al programador de la aplicación.

La función XtIsRealize, que se muestra a continuación, verifica si se ha activado un determinado widget. El widget especificado debe ser de la clase Core o de algún subconjunto de esa clase.

Boolean XtIsRealize(w) Widget w; I* Especifica el widget *I

101


~~~~ ~ ~

Desactivación de los widgets

La función XtUnrealizeWidget desactiva (unrealizes) un caso de un widget. Destruye las ventanas del widget dado y de sus descendientes, pero no destruye las ventanas dinámicas. Entre SUS actividades están las siguientes:

0 Cancelar la asignación de gestión de un widget gestionado.

Ejecutar cualquier procedimiento que se llame XtUnrealizeCallback.

0 Destruir la ventana y cualquier subventana del widget llamando a la hnción XDestroyWindow.

A continuación mostramos dicha función:

void XtUnrealiieWidget(w) Widget w; I* Especifica el widget *I

El widget especificado debe ser de la clase Core o de algún subconjunto de esa clase. Las actividades de la lista anterior son transparentes al programador de la aplicación.

Destrucción de un widget

La función XtDestroyWidget destruye un caso (instance) de widget. La destrucción de widgets requiere dos pasos para eliminar cualquier referencia al widget destruido.

En el primer paso, XtDestroyWidget prepara el widget para la destrucción, pero en realidad no lo destruye, haciendo lo siguiente:

0 Verifica el campo being-destroyed del widget. Si este campo lógico tiene el valor TRUE, el procedimiento retorna sin ir más lejos en el procesamiento. Si el campo being-destroyed del widget es FALSE, el procedimiento pone el campo a TRUE para el widget y todos sus descendientes, incluyendo los hijos de widgets emergentes.

Aiiade el widget a una lista de widgets destruidos. Los descendientes no se pueden encontrar después de su padre en la lista de destrucción.

El segundo paso de la destrucción de widgets se ejecuta sólo después de llamar a todos los procedimientos asociados con el suceso actual. En esta segunda fase. XtDestroyWidget hace lo siguiente:

Llama a los procedimientos de llamadas de retorno de destrucción para el widget y sus descendientes, incluyendo widgets dinámicos, y comenzando desde los hijos.

Llama a la función XtUnmanageChild cuando sea necesario y a continuación llama al procedimiento delete-child del widget padre. Estas llamadas no se realizan para los hijos dinámicos.

Llama a los procedimientos de destrucción para el widget y sus descendientes.

Llama a la función XDestroyWindow para los widgets que tengan ventanas (widgets activos).

0 Desciendo en el árbol de widgets y destruye las ventanas para todas las ventanas dinámicas activas, desasignando la lista de llamadas de retorno y los hijos de widgets compuestos.

Las actividades anteriores son transparentes al programador de la aplicación. Para obtener una información más detallada sobre la destrucción de widgets consulte el manual del sistema.


Los widgets Shell Los widget Shell es un interfaz entre el gestor de ventanas y la aplicación. En la raíz de cada árbol de widgets se encuentra precisamente un widget de interfaz, el cual contiene un Único widget hijo. El widget hijo cubre completamente la interfaz. El widget Shell aísla a su Único hijo del mundo exterior como un cascarón de huevo rodea y asila al huevo del mundo exterior.

Xt Intrinsics define cuatro clases de interfaces disponibles para los usuarios: Overrideshell, Transientshell, TopLevelShell, y ApplicationShell.

La interfaz Overrideshell contiene widgets muy pasajeros cuyas ventanas no están gobernadas por el gestor de ventanas. Los Overrideshell contienen a menudo menús dinámicos.

Transientshell mantiene widgets pasajeros que son hijos de un widget principal. Sus ventanas son gobernadas por el gestor de ventanas. Los Transientshell pueden contener cuadros de diálogo dinámicos.

TopLevelShell mantiene widgets relativamente permanentes asociados con les ventanas del nivel superior de una aplicación.

ApplicationShell mantiene el widget principal de la aplicación. Habitualmente cada aplicación tiene una, y sólo una, interfaz de aplicación.

Recursos

Los recursos son elementos de datos con nombre cuyos valores se pueden cambiar. Los recursos más comunes están asociados con los widgets, pero algunas estructuras de datos pueden contener recursos modificables. Los recursos permiten personalizar las aplicaciones al personal técnico y a los usuarios finales con un mínimo de errores. Si los programadores de aplicaciones (o los programadores de widgets) han empleado sensatamente los valores por omisión de los recursos, la mayor parte de los usuarios podrán cubrir sus necesidades de información sin tener que asignar valores a los recursos. Sin embargo, los usuarios más capacitados pueden personalizar los recursos como vean más conveniente. Para ello, deben estar familiarizados con el orden en que X Window busca las especificaciones de recursos y con las convenciones de nomenclatura.

Orden de especificación de recursos

En el momento de creación del widget, la caja de herramientas determina la especificación de recursos como sigue:

l . Primero busca la especificación de recursos en la lista de argumentos o en el parámetro vururgs de la función de creación de widgets.

2. A continuación busca la especificación de recursos en la base de datos de recursos de visualización.

3. Finalmente, si la caja de herramientas no puede encontrar la especificación de recursos en la función de creación de widgets ni en la base de datos del recurso de visualización, entonces asigna al widget el valor de recurso por omisión para su clase de widget particular. Este valor se puede heredar de algunas de las superclases de widgets.

103


Nota. Es muy importante escribir correctamente los nombres de los recursos. Un nombre mal escrito no generará un mensaje de error. En su lugar, generará un recurso erróneo. Tales errores pueden ser bastante dificiles de detectar.

Convenios de nomenclatura de los recursos

Para reducir la frecuencia de errores al nombrar los recursos, se utilizan las siguientes convenciones de nomenclatura:

Los nombres de los recursos comenzarán con una letra minúscula y las palabras individuales por mayúscula. El nombre del recurso debe referenciar nombres de campo con sólo letras minúsculas y subrayados. Su nombre simbólico (symbolic name) es el nombre del recurso precedido con la cadena ''XtN', El compilador puede detectar errores de ortografia en el nombre simbólico.

Los nombres simbólicos de las clases de recursos han de comenzar con la cadena "XtC". Las clases de recursos (resource classes) son grupos de recursos relacionados a los que se les puede asignar un valor común. Por ejemplo, a todas las anchuras de borde se les puede asignar un valor de 2.

Utilicemos los tipos de representación de recursos, cuyos nombres comienzan con la cadena "XtR" seguidos por una letra mayúscula y que están definidos en el archivo de cabecera <X11 / StringDefs.h >.

La Tabla 5-2 lista en orden alfabético los tipos de recursos que aparecen en el archivo de cabecera <X11 f StringDefs.h >, su tipo y dónde están definidos.

Caracteres comodines en la especificación de recursos

La especificación de recursos (resource speclfication) indica el valor de recurso para un widget o un grupo de widgets relacionados. Una especificación de recurso explícita de un determinado widget lista los nombres de todos sus ascendientes, comenzando por el widget Shell. También se incluye el nombre del programa, y el nombre y valor seleccionado del recurso especificado.

Tabla 5-2. Tipos de representación de recursos.

Tipo de recurso Campo Definido en

XtRAcceleratorTable XtAccelerators Intrinsics XtRAtom Atom Xlib XtRBitmap Pixmap Xlib XtRBoolean Boolean Intrinsics XtRBool Boo1 Xlib XtRCallback XtCallbacklist Intrinsics XtRCardinal Cardinal Intrinsics XtRColor XColor Xlib XtRColorMap Colormap Xlib XtRCursor Cursor Xlib XtRDimension Dimension Intrinsics XtDisplay Display Intrinsics XtREnum XtEnum Intrinsics XtlUile FILE <stdio.h> XtRFloat float Lenguaje C XtRFont XFontstruct Xlib XtRFunction Lenguaje C XtRGeometry String Intrinsics


~~~~~

XtRInitialState XtRInt XtRLongBoolean XtRObject XtRPixel XtRFixmap XtRPointer XtRPosition XtRScreen XtRShort XtRString XtRStringArray XtRStringTable XtRTranslationTable XtRUnsignedChar XtRVisual XtRWidget XtRWidgetClass XtRWidgetList XtRWindow

int int long Object Pixel Pixmap XtPointer Position Screen short String String String XtTranslation unsigned char Visual Widget Widgetclass WidgetList Window

ICCCM Lenjuage C Lenguaje C Intrinsics Xlib Xlib Intrinsics Intrinsics Xlib Lenguaje C Intrinsics Intrinsics Intrinsics Intrinsics Lenguaje C Xlib Intrinsics Intrinsics Intrinsics Xlib

Por ejemplo, en la primera versión del programa “Hola Mundo” de este capítulo, podemos establecer el color del borde del widget hellow a gris con la siguiente especificación de recurso:

ejempto1.XHellow.hellow.borderColor: gray

El valor ejemplo1 indica el nombre del programa. El valor XHellow señala el nombre del widget Shell, el cual es también la clase de aplicación. El valor hellow referencia al nombre del widget, devuelto por la función XtVaCreateManagedWidget. Al recurso borderColor se le da el valor gray (gris).

El codificar las especificaciones de recursos de forma explícita puede ser tedioso. E l uso apropiado de los caracteres comodines (*) simplifica el trabajo de codificación cuando, como sucede a menudo, recursos similares asumen el mismo valor. Por ejemplo, para asignar un color de borde gris a todos los widgets hijos del widget Shell XHellow, escribiremos la especificación de recurso siguiente:

ejemplol.XHellow*borderCoLor: gray

El asterisco indica que para el programa ejemplo 1, todos los widgets descendientes del widget XHellow (el widget Shell) tienen un color de borde gris.

El símbolo del carácter comodín es bastante potente. Para asignar un color de borde gris a todos los widgets. se ha de escribir la especificación de recurso siguiente:

*borderColor: gray

Estas especificaciones de recursos se pueden guardar dentro de la base de datos de recursos usando funciones Xlib como XrmPutResource. Muchas aplicaciones no crean ni modifican la base de datos de recursos. Sin embargo, pueden especificar recursos que anulen las especificaciones de recursos de la base de datos.

Todos los widgets de la clase de recurso XtCBorderColor se pueden poner a gris con la siguiente especificación:

*Bordercolor: gray

105


Archivos de recursos

Los usuarios pueden especificar los recursos deseados en la línea de órdenes como se muestra en la Tabla 5-3.

Varios ejemplos nos muestran cómo especificar los recursos de ventana a través de la línea de órdenes.

La siguiente orden ejecuta la aplicación prog, generando una ventana cuya anchura es de 200 puntos (pixels) y cuya altura es de 150 puntos en la pantalla. El borde derecho de la ventana está a 20 puntos del interior del borde derecho de la pantalla y a 25 puntos por debajo de la parte superior de la pantalla.

prog -geometry 200x150-20+25

Tabla 5-3. Especificaciones de recursos en la línea de órdenes.

Opci6n Nombre del recurso Valor del recurso

-background " b g "bordercolor " b d "borderwidth

d i s p l a y -foreground -fg -font " f n "geometry -iconic -name "reverse -rv frV

"selectionTimeout "synchonous + synchonous

"title "xnllanguaje

-bW

"xrm

*background *background *bordercolor *borderColor .borderwidth .borderwidth .display *foreground *foreground *font *font .geometry .iconic .name .reversevideo .reversevideo .reversevideo .selectionTimeo ut .synchronous synchronous .title .xnlLanguaje siguiente argumento

Siguiente argumento Siguiente argumento Siguiente argumento Siguiente argumento Siguiente argumento Siguiente argumento Siguiente argumento Siguiente argumento Siguiente argumento Siguiente argumento Siguiente argumento Siguiente argumento "on" Siguiente argumento "on" "on" "off' Siguiente argumento "on" "off' Siguiente argumento Siguiente argumento Siguiente argumento

La siguiente orden sitúa una ventana cuya anchura es de 200 puntos y cuya altura es de 150 puntos en la pantalla. El borde izquierdo de la ventana está a 20 puntos por dentro del borde izquierdo de la pantalla y a 25 puntos por debajo de la parte superior de la pantalla.

prog -geometry 200x150+20+25

La siguiente orden da al fondo de la ventana el color gris brillante y al primer plano el color amarillo. Hemos de tener cuidado de no cansar la vista con este tipo de órdenes.

prog -bg Lightgray -fg yellow

Recursos del widget Core (núcleo)

La Tabla 5-4 lista los recursos de los widgets Core (núcleo). Un tipico nombre de recurso de núcleo es XtNborderColor. Este recurso pertenece a la clase XtCBorderColor. Normalmente, para obtener el

106


nombre de la clase a partir del nombre del recurso, debemos sustituir la tercera letra (N) por una C y escribir en letra mayúscula la próxima letra. Más adelante se indica el nombre de clase en los casos en que no se aplica la regla de transformación de nombres. Motif sustituye la segunda letra (t) en el nombre de recurso y en la clase de recurso por una m; por ejemplo, Motif define un nombre de recurso XmNborderColor y el nombre de clase del recurso asociado XmCBorderColor. Hay que tener cuidado con la ortografia, se producen con facilidad errores y sé localizan con dificultad.

Tabla 5-4. Recursos de los widgets Core (núcleo).

Nombre Tipo Valor por omisión

XtNdestroyCallback XtNx XtNy XtNwidth XtNheight XtNsensitive XtNancestorsensitive XtNscreen XtNdepth XtNcolormap XtNbackground XtNbackgroundPixmar XtNborderWidth XtNborderColor XtNborderPixmap XtNmappedWhenManaged XtNtranslations XtNaccelerators

XtCallbackList Position Position Dimension Dimension boolean boolean Puntero le pantalla Cardinal Puntero al mapa de colores Pixel Pixmap Dimension Pixel Pixmap Boolean XtTranslations XtAccelerators

NULL O O O O TRUE TRUE (Descripción a continuación) (Descripción a continuación) (Descripción a continuación) (Descripción a continuación) (Descripción a continuación) 1 (Descripción a continuación) (Descripción a continuación) TRUE (Descripción a continuación) None

El recurso XtNdestroyCallback es una lista de procedimientos de llamadas de retorno que se llama cuando se destruye el widget. Su nombre de clase es XtCCallback. Las aplicaciones no utilizan a menudo este recurso.

Los recursos XtNx, XtNy, XtNwidth, XtNheight, y XtNborderWidth determinan la geometría de la ventana dei widget. Los recursos XtNx y XtNy tienen el nombre de clase XtCPosition. Siempre se usan estos recursos para mover y redimendionar los widgets; si usamos la llamada a la función correspondiente de Xlib, Xt Intrinsics dispondrá de una mformación incorrecta sobre la geometría de la ventana del widget.

Los recursos XtNsensitive y XtNancestorsensitive pertenecen a la clase de nombre XtCSensitive. Indican si un widget reaccionará a una entrada de usuario y, consecuentemente, llamaran a la h c i ó n de llamada de retorno apropiada. La sensibilidad se propaga hacia abajo de padres a hijos. Para desconectar un widget de botón, se ha de dar a su recurso XtNsensitive el valor FALSE usando la función XtSetSensitive. El recurso XtNacestorsensitive indica si el padre de un widget (o ascendiente de éste) reacciona ante las entradas de usuario. Las aplicaciones no pueden modificar este recurso.

Los recursos XtNscrcen, XtNdepth, XtNcolormap contienen punteros a la pantalla de visualización, profhdidad de la pantalla (número de bits por pixel), y al mapa de colores. Sólo los widgets interfaces especifican el recurso XtNscreen; los otros widgets se visualizan sobre la misma pantalla que sus padres. El recurso XtNdepth debe especificarse sólo en el momento de creación del widget, Los widgets Shell de nivel superior obtienen los valores por omisión para estos recursos de los valores por omisión de la ventana raiz; los otros widgets obtiene los valores por omisión de sus padres.

Los recursos XtNbackground, XtNbackgroundPixmap, XtNborderWidth, XtNborderColor, y XtNborderPixmap determinan los atributos color de fondo y borde del widget. Los recursos

107


XtNbackgroundPixmap y XtNborderPixmap tienen el nombre de clase XtCPixmap. Podemos establecer el color de fondo o el mapa de puntos del fondo, pero no ambos. El ultimo recurso que se fija tiene precedencia. La misma regla se utiliza para el color del borde y mapa de puntos del borde. El valor por omisión del recurso XtNbackground es XtDefaultBackground, normalmente con el valor Whitepixel. El valor por omisión del recurso XtNbackgroundPixmap es XtUnspecificedPixmap, el cual hace que se utilice el fondo señalado por XtNbackground. El valor por omisión del recurso XtNborderColor es XtDefaultForeground, normalmente con el valor BlackPixel. El valor por omisión del recurso XtNborderPixmap es XtUnspecifiedPixmap.

El recurso XtNmappedWhenManaged indica si cuando su padre le asigna espacio y gestiona su geometría, el widget aparece en pantalla.

El recurso XtNtranslations define una tabla de transformación que contiene los sucesos de entrada generados por el servidor en widgets y funciones de la aplicación. El programador de widgets define un valor por omisión para todos los widgets pertenecientes a una determinada clase. El recurso XtNaccelerators define una tabla de transformación ampliada que asocia un suceso a un widget y su efecto sobre otros widgets.

Recursos de los widgets Composite (compuestos)

La clase de los widgets Composite (compuestos) es una superclase de otras clases. En las aplicaciones no se crean widgets pertenecientes a la clase de widgets Composite. Las aplicaciones usan raramente alguno de los siguientes recursos:

Nombre Tipo Por omisión

XtNinsertF'osition XtOrderProc insertAtEnd XtNchildren Puntero a un widget (Sigue la descripción) XtNnumChildren Cardinal (Sigue la descripción)

El recurso XtNinsertPosition de tipo XtOrderProc especifica un procedimiento que devuelve la nueva posición del hijo en la lista de hijos.

Los recursos asociados XtNchildren y XtNnumChildren (ambos de la clase XtCReadOnly) proporcionan la lista y número de hijos.

Un widget compuesto es responsable de la gestión de sus hijos, en los siguientes aspectos:

Gestiona la geometría de los widgets hijos, o sea el tamaño, anchura del borde, posición en la pantalla, y orden de apilamiento del widget, para los hijos del widget.

Visualiza y cancela la visualización de sus hijos del widget.

0 Decide el hijo sobre el que se encuentra focalizada la entrada de Xteclado, en otras palabras, el hijo recibe la entrada de teclado en un determinado momento.

0 AI ser destruido devuelve la memoria al sistema, lo cual, en el caso de la memoria de un widget Composite, es sólo después de que hayan sido destruidos todos sus hijos.

108


Llamadas de retorno Un aspecto esencial de la programación con la caja de herramientas es el uso de funciones de llamada de retorno (callbacks), que informan a una aplicación de que un usuario ha referenciado un widget. Raro es el programa de la caja de herramientas que no contenga al menos una función de llamada de retorno. Habitualmente, las aplicaciones basadas en la caja de herramientas no solicitan directamente entradas de usuario, sino que llaman a un procedimiento de la caja de herramientas que gestiona las solicitudes de entrada de usuario y llama a las rutinas de llamadas de retorno apropiadas.

Los diseñadores de widgets determinan el procedimiento o procedimientos de llamada de retorno específicos para sus widgets. Por ejemplo, un widget Scrollbar (barra de desplazamiento) podría tener diferentes llamadas de retorno para mover el cursor y para desplazar hacia arriba o abajo una página o un elemento. Por otro lado, el diseñador de widgets puede crear un widget más sofisticado con un sencillo procedimiento de llamada de retorno. En este caso, el propio widget hace los cálculos necesarios. La aplicación pasa a ser más sencilla, pero el widget será m á s complicado.

Codificación de los procedimientos de llamada de retorno

Los procedimientos de llamada de retorno son del tipo XtCallbackProc. Estos tienen la forma siguiente:

typedef void (*XtCallbackProc) (w, client-data, call-data) Widget w; I* Especifica el widget al que se liga la llamada de retorno */ XtPointer client-data; /* Elemento de datos definido por la aplicaci6n */ XtPointer call-data; /* Elemento de datos definido por la clase del widget */

Los widgets simples, como Pushbutton (Botón), asignan habitualmente al partimetro call-data el valor NULL. Podemos utilizar un Único procedimiento de llamada de retorno para más de un widget. En este caso, la llamada de retorno comprueba el parámetro call-data para determinar el tipo de widget. Intrinsics pasa el parámetro client-data a la aplicación s i n ninguna interpretación.

Adición y eliminación de llamadas de retorno

Cinco funciones Xt Intrinsics añaden y eliminan llamadas de retorno: XtAddCallback, XtAddCallbacks, XtRemoveCallback, y XtRemoteCallbacks, XtRemoveAllCallbacks elimina todas las llamadas de retorno de una determinada lista de llamadas de retorno. XtHasCalbacks comprueba el estado de una lista de llamadas de retorno.

La función XtAddCalIback, que se muestra a continuación, añade el procedimiento de llamada de retorno especificado a la lista de llamadas de retorno del widget elegido.

void XtAddCallback(w, callback, client-data) Widget w; /* Especifica el widget al que afladir los procedimientos de llamada

String callback-name; I* Especifica la lista de llamadas de retorno a la que afladir

XtCallbackProc callback; I* Especifica el procedimiento de llamada de retorno *I XtPointer client-data; I* Especifica el valor pasado al procedimiento de llamada de

de retorno *I

los procedimientos de llamada de retorno *I

retorno o NULL *I

A continuación, la función XtAddCallbacks añade la lista de procedimientos de llamada de retorno, tenninada por una cadena NULL, a la lista de llamadas de retorno del widget elegido.

1 o9


void XtAddCallbacks(w, callback-name, callbacks) Widget w; I* Especifica el widget al que afiadir los procedimientos

de llamada de retorno */ String callback-name; /* Especifica la lista de llamadas de retorno a la que aAadir

los procedimientos de llamada de retorno *I XtCallbackList callbacks; /* Especifica la lista de procedimiento de llamada de retorno

y los datos del cliente asociados */

La función XtRemoveCallback, que se muestra a continuación, elimina el procedimiento de llamada de retorno especificado de la lista de llamadas de retorno del widget elegido.

void XtRemoveCallback(w, callback-name, callback, client-data) Widget w; /* Especifica el widget del que eliminar el procedimiento

String callback-name; I* Especifica la lista de llamadas de retorno de la que eliminar

XtCallbackProc callback; /* Especifica el procedimiento de llamada de retorno

XtPointer client-data; /* Especifica los datos del cliente que han de

de Uamada de retorno */

el procedimiento de llamada de retorno */

a eliminar de la lista *I

corresponder con los del procedimiento a eliminar */

Los datos del cliente y del procedimiento deben coincidir para que XtRemoveCallback elimine el procedimiento.

A continuación, la función XtRemoveCallbacks elimina todos los procedimientos de llamada de retorno señalados de la lista de llamadas de retorno del widget elegido.

void XtRemoveCallbacks(w, callback-name, callbacks) Widget w; /* Especifica el widget del que eliminar los procedimientos

de llamadas de retorno */ String callback-name; /* Especifica la lista de llamadas de retorno de la que eliminar

los procedimientos de llamada de retorno *I XtCallbackList callbacks; /* Especifica la lista de procedimientos de llamada de retorno

con los datos del cliente asociados */

Los datos del cliente y de los procedimientos deben coincidir para que XtRemoveCallbacks elimine los procedimientos.

La función XtRemoveAllCallbacks, que mostramos a continuación, elimina todos los procedimientos de llamadas de retorno de la lista especificada.

void XtRemoveAllCallbacks(w, callback-name) Widget w; /* Especifica el widget del que eliminar todos

String callback-name; I* Especifica la lista de llamadas de retorno a eliminar */ los procedimientos de llamada de retorno */

A continuación sigue la función XtHasCallbacks que comprueba el estado de una lista de llamadas de retorno.

typedef enum{ XtCallbackNoList, XtCallbackHasNone, XtCallbackHasSome,

} XtCallbackStatus; XtCallbackStatus XtHasCallbacks (w, callback-name)

Widget w; I* Especifica el widget a comprobar *I String callback-name; /* Especifica la lista de llamadas de retorno

a comprobar */

110


Si el widget no posee la lista de llamadas de retomo especificada, XtHasCallbacks devuelve el valor XtCallbackNoList. Si dicha lista existe pero está vacía, devuelve el valor XtCallbackHasNone, y si existe y al menos tiene un procedimiento de llamada de retorno, devuelve el valor XtCallbackHasSome.

Ejemplo 3: Un programa que utiliza el widget RowColumn El próximo ejemplo utiliza un widget compuesto RowColumn para crear tres botones el botón f (rbutton), que contiene la cadena de caracteres "Levi Reiss"; el botón S (sbutton), que contiene la cadena de caracteres "Joseph Radin", y el botón t (tbutton), el cual contiene la cadena de caracteres "Para salir pulse aquí".

La siguiente rutina de llamada de retomo incluye la función exit (salir), la cual termina la ejecución del programa cuando se le llama, tal y como indica su nombre.

void tbutton-func(w, client-data, call-data) Widget w; XtPointer client-data; XtPointer call-data; I

printf("Ha seleccionado el b o t h t y el programa terminara\n); exit(0);

I

Para crear todos los widgets, excepto el de nivel superior, se llama varias veces a la función XtVaCreateManagedWidget. Cada llamada incluye cuatro argumentos: el nombre del widget entre comillas, la clase del widget, el widget padre, y NULL para terminar la lista varargs. El widget "rc" pertenece a la clase xmRowColumnWidgetClass, y sus tres widgets hijos pertenecen a xmPushButtonWidgetClass. Por ejemplo,

rc = XtVaCreateManagedWidget("rc", xmRowColumnWidgetClass, theparent, NULL);

Y

!button = XtVaCreateManagedWidget("fbutton", xmPushButtonWidgetClass, rc, NULL);

Las tres funciones de creación de widget de botón se entremezclan con llamadas a la función XtAddCallback, que a su vez incluye cuatro parámetros en este caso, el widget que acciona la llamada de retorno; la lista de recursos de llamadas de retorno; el procedimiento de llamada de retorno definido al inicio del programa, y O , ya que no se pasan datos al procedimiento de llamada de retorno Un ejemplo típico de uso de esta función es

XtAddCallback(fbutton, XmNactivateCallback, fbutton-func, O)

A continuación se ofrece el listado completo del ejemplo 3.

I* Paso1 Archivo de cabecera Motif *I #include <Xm/Xm.h>

I* Paso 2 Archivos de cabecera pdblicos para la clase de widgets usados *I #include <Xm/RowColumn.h> #include <Xm/PushB.h>

111


I* Llamada de retorno para le primer bo th definido *I

void mutton-func (w, client-data, call-data) Widget w; XtPointer client-data; XtPointer call-data; /* Imprime si se ejecuta la llamada de retorno *I {

I printf(“Ha seleccionado el boton f .. . \o”);

I* Llamada de retorno para el segundo bo th definido *I void sbutton-func(w, client-data, call-data) Widget w; XtPointer client-data; XtPointer call-data; {

I printf(“Ha seleccionado el boton S ... b”);

I* Llamada de retorno para el tercer bo th definido */ void tbutton-func(w, client-data, call-data) Widget w; XtPointer client-data; XtPointer call-data; { printf(“Ha seleccionado el boton t y el programa terminara b”); exit(0);

I

I* Paso 3 Inicializaci6n del programa y de la herramienta *I

main(argc, argv) int argc; char *argv[];

I* Declaraci6n de variables con estructura de datos de tipo Window */ Window theparent, rc, fbutton, sbutton, tbutton; XtAppContext app-context;

{

theparent = XtVaAppInitialize(&app-context, “XExamplB”, NULL, O, &argc, argv, NULL, NULL);

I* Paso 4 Creaci6n y gesti6n de los widgets *I rc = XtVaCreateManagedWidget(“rc”,

xmRowColumnWidgetClass, theparent, NULL);

fbutton = XtVaCreatemanagedidget(%utton”, xmPushButtonWidgetClass, rc, NULL);

I* Paso 5 Afíadir una funci6n de llamada de retorno */

XtAddCallback(fbutton,XmNactivateCallback, fbutton-func, O);

sbutton = XtVaCreateManagedWidget(“sbutton”, xmPushButtonWidgetClass, re, NULL);

XtAddCallback(sbutton,XmNactivateCallback, sbutton func, O);

112


tbutton = XtVaCreateManagedWidget("tbutton", xmPushButtonWidgetClass, rc, NULL);

XtAddCallback(tbutton,XmNactivateCallback, tbutton-func, O);

I* Paso 6 Activaci6n del widget */ XtRealieWidget(theParent);

I* Paso 7 Bucle de Sucesos *I XtAppMainLoop(app-context);

I

Figura 5-4. Destacando la ventana derecha de un Widget RowColumn.

En la figura 5-4 se muestra el resultado de la ejecución de este programa. El siguiente archivo MAKE se usó para procesar este programa en SCO Open Desktop. Para otras implementaciones de X Window este archivo sería distinto.

RM = rm -rf cc = cc CFLAGS = -0 INCLUDES = -Uusr/include -Uusr/include/Xll LIBS = -IXm -1Xt 4x1 1 -1socket -1malloc -1PW

$(m) $63 .c.o:

$(CC) -c $(FLAGS) $(INCLUDE) %*.c all::ejemplo3 ejemplo3: ejemplo3.0

%(CC) "o $@ $(FLAGS) ejemplo3.0 $(LIBS) @echo Terminada la ejecuci6n del archivo de construcci6n del ejemplo 3

W M ) $63

Ejemplo 4: Un programa que usa varios widgets

El siguiente programa muestra cómo se crean varios widgets de diferentes tipos. Genera un widget Mainwindow que gestiona la geometría de su arrea de trabajo con una barra de desplazamiento y un

113


-~ ~ ~

widget Frame (marco), el cual es un área vacía que parece tridimensional. Al presionar un botón aparece otro botón que le permite al usuario abandonar el programa.

Esta aplicación más complicada requiere el uso de siete archivos include. El archivo de inclusión estándar de Motif es <Xm/Xm.h>. El archivo <xm/MainW.h> es necesario para crear el widget Mainwindow. Para el widget RowColumn es necesario el archivo <Xm/RowColumn.h> que se usó en el ejemplo anterior. El archivo <Xm/Frame.h> define los widgets Frame. Como en el ejemplo anterior, el archivo < XmiPushB.h > se usa con el widget PushButton. < Xm CascadeB.h > se usa con los botones Cascade (en cascada) que pulsaremos para desplegar un menú, y <Xm/MessageB.h> para los cuadros con mensajes de ayuda.

La función XmCreateMenuBar crea un widget RowColumn especial conocido como barra de menú. Como ésta sólo crea la barra del menú pero no lo gestiona, ha de seguirla la función XtManageChild. Después de crear el widget Frame, el programa llama a la función XmMainWindowSetAreas que defiie los widgets de la ventana principal. Aunque Mainwindow es una subclase de ScrolledWindow, es una buena idea definir la barra de desplazamiento de la ventana principal de forma que se obtenga la máxima flexibilidad. La función XmCreatePulldownMenu crea el menú desplegable. La función XtVaSetValues establece los recursos para el widget de botón.

A continuación se muestra el listado completo del programa del ejemplo 4.

#include<Xm/Xm.h> #include<Xm/MainW.h> #include<Xm/RowColumn.h> #include<Xm/Frame.h> #includecXm/PushB.h> #include<Xm/CascadeB.h> #include<Xm/MessageB.h>

/* Llamada de retorno para le b o t h de salida definido */ void quitbutton-func(w, client-data, call-data) Widget w; XtPointer client-data; XtPointer call-data;

/* Imprimir si se ha ejecutado la llamada de retorno de salida *I { printf(“Ha seleccionado el bo th de salida y el programa terminara\n”); exit(0);

I

main(argc,argv) int argc; char *argv[];

Window theparent, thewindow, thebar, theframe, thebutton, themenu, quitbutton; XtAppContext app-context;

{

theparent = XtVaAppInitialize(&app-context, “XExample4”, NULL, O, &argc, argv, NULL, NULL);

thewindow = XtVaCreateManagedWidget(“thewindow”, XmMainWindowWidgetClass, theparent, NULL);

thebar = XmCreateMenuBar(thewindow, “thebar”, NULL, O);

XtManageChild(thebar);

theframe = XtVaCreateManagedWidget(“theframe“, XmFrameWidgetClass,

114


~~ ~

thewindow, NULL);

XmMainWindowsetAreas(thewindow, thebar, NULL, NULL, NULL, theeframe);

thebutton = XtVaCreateManagedWidget(“thebutton”, xmcascadeButtonWidgetClass, thebar, NULL);

themenu = XmCreatePulldownMenu(thebar, “themenu”, NULL, O);

quitbutton = XtVaCreateManagedWidget(“quitbutton”, xmPushButtonWidgetClass, themenu, NULL);

XtVaSetValues(thebutton, XmNsubMenuId, themenu, NULL);

XtAddCallback(quitbutton, XmNactivateCallback, quitbutton-func, O);

XtRealizeWidget(theParent);

XtAppMainLoop(app-context); 1

El resultado de la ejecución de este programa se muestra en la Figura 5-5. El siguiente archivo MAKE se usó para procesar este programa en SCO Open Desktop, Para otras implementaciones de X Window este archivo sería distinto.

RM=rm-f cc = cc CFLAGS = -0 INCLUDES = -Yusr/nclude -Uusr/include/Xll LIBS = -Ixm -1Xt 4x1 1 -1socket -1malloc -1PW .c.o: $0 S@ $(CC) -c $(FLAGS) $INCLUDES) $*.c all:: ejemplo4 ejemplo4: ejemplo4.0

%(CC) -o S@ %(FLAGS) eje,plo4.0 $(LIBS) @echo Terminada la ejecuci6n del archivo de construcci6n del ejemplo 4

W M ) S@

Widgets dinámicos (popups)

Los widgets dinámicos (popups) son widgets transitorios: aparecen en la pantalla por un corto periodo de tiempo. La mayoría de los widgets dinámicos son menús o cuadros de diálogo. Un cuadro de diálogo (dialog b o w es un recuadro visualizado en primer plano que requiere de una entrada de usuario, muestra un mensaje, o ambas cosas. Por ejemplo, se puede requerir a un usuario que confirme la supresion de archivos mediante cuadros de dialogo. Los cuadros de dialogo permanecen en la pantalla sólo durante el dialogo. Por ejemplo, cuando el usuario intenta borrar un archivo aparece un cuadro y cuando éste c o n f i i a o cancela la supresión del archivo desaparece. Pulsando un botón Cascade se despliega un menú. El menú desaparece cuando el usuario selecciona una opción.

Motif ofrece varia funciones para crear widgets dinámicos. La función XmCreatePopupMenu crea un menú dinámico al que se puede llamar presionando un botón en la ventana seleccionada o en la ventana principal de la aplicación. El menú aparece habitualmente en la posición del puntero. La fimción XmCreatePulldownMenu crea un menú desplegable que se posesiona justo debajo del botón que lo creó directamente. A pesar de su nombre, un menú desplegable es un tipo de menú dinámico.

115


Figura 5-5. Los widgets PushButton después de pulsar el primero.

Hay cinco pasos para la creación de un menú desplegable:

1. Crear una barra de menú.

2. Crear un botón xmCascadeButtonWidgetClass que es un hijo de la barra de menú

3. Crear un menú vacío usando a XmCreatePulldownMenu como un hijo de la barra de menú.

4. Crear botones (widgets de la xmPushButtonWidgetClass) como hijos del menú de botón.

5. Hacer aparecer el menú desplegable (Cascade).

Estos pasos se ilustran en el programa del ejemplo 5.

Ejemplo 5: Programa con un menú de ayuda dinamico

El último ejemplo de este capítulo crea un menú de ayuda dinámico. Incluye unos pocos elementos que merecen un comentario aparte. Las líneas de código que se ofrecen a continuación asignan el parámetro client-data una variable local de tipo Widget y llaman a la función XtManageChild para situar el widget de diálogo en la pantalla.

{ Widget keep-data;

keep-data = client-data; printfpha seleccionado el bot611 de ayuda ... \n"); XtManageChild(kepp-data);

1

116


~~ ~

Las líneas siguientes crean el widget asociado con el cuadro Help (ayuda).

thehelp = XtVaCreateManagedWidget(“thehelp”, xmCascadeButtonWidgetClass, thebar, NULL);

XtVaSetValues(thebar, XmNmenuHelpWidget, thehelp, NULL);

thehelpbox = XmCreateMessageDialog(thehelp, “thehelpbox”, NULL, o);

El cuadro estándar incluye un botón Cancel y un botón HELP. Las siguientes líneas eliminan estos dos botones.

dummy = XmMessageBoxGetChild(thehelpbox, xmDIALOG-CANCEL-BUTTON); XtUnmanageChild(dummy); dummy = XmMessageBoxGetChild(thehelpbox, XmDIALOG-HELP-BUTTON);

A continuación se muestra el listado completo del programa del ejemplo 5.

#include<Xm/Xm.h> #include<Xm/MainW.h> #include<Xm/RowColumn.h> #include<XmlFrame.h> #include<XmlPushB.h> #include<Xm/CascadeB.h> #include<Xm/MessageB.h>

void help-func(w, client-data, call-data) Widget w; XtPointer client-data; XtPointer call-data;

Widget keep-data; I

keep-data = client-data; printf(“Ha selecionado el bo th de ayuda ...”); XtManageChild(kepp-data);

1

void quitbutton-func(w, client-data, call-data) Widget w; XtPointer client-data; XtPointer call-data; i

printf(“Ha seleccionado el bo th de salida y el programa terminah”); exit(0);

I

main(argc, argv) int argc; char argv[]; I

Window theparent, thewindow, thebar, theframe, thebutton, themenu, quitbutton; Window thehelp, thehelpbox, dummy; XtAppContext app-context;

theparent = XtVaAppInitialize(&app_context, “XExampleS”, NULL, O, &argc, argv, NULL, NULL);

thewindow = XtVaCreateManagedWid.get(“thewindow”,

117


xmMainWindowWidgetClass, theparent, NULL);

thebar = XmCreateMenuBar(thewindow, “thebar”, NULL, O);

XtManageChild(thebar);

theframe = XtVaCreateManagedWidget(“theframe”, XmFrarneWidgetClass, thewindow, NULL);

xmMainWindowSetAreas(thewindow, thebar, NULL, NULL, NULL, theframe);

thebutton = XtVaCreateManagedWidget(“thebutton”, xmCascadeButtonwidgetClass, thebar, NULL);

themenu = XmCreatePulldownMenu(thebar, “themenu”, NULL, O);

XtVaSetValues(thebutton, XmNsubMenuId, themenu, NULL);

XtAddCallback(quitbutton, XmNactivateCallback, quitbutton-func, O);

thehelp = XtVaCreateManagedWidget(“thehelp”, xmCascadeButtonWidgetClass,

thebar, NULL);

XtVaSetValues(thebar, XmNmenuHelpWidget, thehelp, NULL);

thehelpbox = XmCreateMessageDialog(thehelp, “thehelpbox”, NULL, O);

dummy = XmMessageBoxGetChild(thehelpbox, XmDIALOG-CANCEL-BUTTON);

XtUnmanageChild(dummy);

dummy = XmMessageBoxGetChild(thehelpbox, XmDIALOG-HELP-BUTTON);

XtUnmanageChild(dummy);

XtAddCallback(thehelp, XmNactivateCallback, help-func, thehelpbox);

XtRealizaWidget(theParent);

XtAppMainLoop(app-context);

El resultado de la ejecución de este programa se muestra en la Figura 5-6:

118


Figura 5-6. Estado inicial de un menú dinámico.

Figura 5-7. Función de ayuda de un menú dinámico.

El siguiente archivo MAKE se usó para procesar este programa en SCO Open Desktop. Para otras aplicaciones de X Window este archivo sería distinto.

RM = rm -f cc = cc CFLAGS = -0 INCLUDES = -I/usr/include -I/usr/include/Xll LIBS = -1xm -1Xt 4x1 1 -1socket -1malloc -IPW

$(RM) $@ .c.o:

$(CC) -c %(FLAGS) %INCLUDES) $*.c all:: ejemplo5 ejemplo5: ejemplo5.0

%(CC) "o $@ %(FLAGS) ejemplo5.0 S(L1BS) @echo Terminada la ejecuci6n del archivo de construcci6n del ejemplo 5

$(RM) %@

119

Herramientas, conceptos y tkcnicas

EspeciJicación de recursos de todos los ejemplos

La siguiente especificación de recursos es válida para todos los ejemplos simultáneamente o por separado. Por ejemplo, la especificación de recurso

*borderWidth:2

indica que la anchura de todos los bordes es de dos puntos, a menos que se especifica otra cosa. La especificación de recurso

*hellow.foreground:black

asociado con el ejemplo 1, indica que el primer plano del widget hellow es negro.

fontList:times-bold*lt?O*iso8859-1 *borderWidth:2 *XmRowColumn.XmPushButton.background: lightgray *XmRowColumn.XmPushButton.foreground: white *XmRowColumn.XmPushButton.borderColor: black

# COMIENZO DE LAS ESPECIFICACIONES DE RECURSOS DEL EJEMPLO1 *hellow.width: 445 *hellow.height: 50 *hellow.alignment:XmALIGNMENT-END *hellow.background: lightgray *hellow.foreground:black *hellow.labelString: Levi Reiss y Joseph Radin

- X Window Inside and Out

# FIN DE LAS ESPECIFICACIONES DE RECURSOS DEL EJEMPLO1 # # # # COMIENZO DE LAS ESPECIFICACIONES DE RECURSOS DEL EJEMPLO2 *ghellow.width: 445 *ghellow.height: 100 *ghellow.alignment:XmALIGNMENT-END *ghellow.background: gray *ghellow.foreground: black *ghellow.labelString: Levi Reiss y Joseph Radin # FIN DE LAS ESPECIFICACIONES DE RECURSOS DEL EJEMPLO2 # # # # COMIENZO DE LAS ESPECIFICACIONES DE RECURSOS DEL EJEMPLO3 *rc.packing: XmAPCK-TIGHT *rc.background gray *rc.foreground: white *rc.borderColor: black *rc.orientation: XmHORIZONTAL *tbutton.labelString: Levi Reiss *tbutton.labelString: Para salir pulse aqui # FIN DE LAS ESPECIFICACIONES DE RECURSOS DEL EJEMPLO3 # # # # COMIENZO DE LAS ESPECIFICACIONES DE RECURSOS DEL EJEMPLO4

120


*thewindow.width: 500 *thewindow.scrollingPolicy: XmAUTOMATIC *thewindow.background: gray *thewindow.foreground: lightgray *thebar.background: gray *thebar.foreground: black *theframe.width: 700 *theframeheight: 700 *theframe.background: lightgray *theframe.foreground: gray *theframe.borderColor: white *themenu.background: white *themenu.foreground: gray *thebutton.background: white *thebutton.foreground: black *thebutton.borderColor: white *thebutton.labelString: Presione aqui y vea . .. *quitbutton.labelString: Pulse aqui para salir *quitbutton.background: gray *quitbutton.foreground: black *quitbutton.borderColor: white # FIN DE LAS ESPeCIFICACIONES DE RECURSOS DEL EJEMPLO4 # # # # COMIENZO DE LAS ESPECIFICACIONES DE RECURSOS DEL EJEMPLO5 *thehelp.width: 200 *thehelpscrollingPolicy: XmAUTOMATIC *thehelp.background: lightgray *thehelp.foreground: black *thehelp.borderColor: white *thehelp.labelString: Pulse aqui para ayuda *thehelpbox.background: gray *thehelpbox.foreground: black *thehelpbox.width: 300 *thehelpbox.heigth: 400 *thehelpbox.messageString: En este ejemplo se crea un menú dinhmico: \n\n el bo th -Pulse aqui y vea:\n\ - cuando lo pulse veri un bot611 dinhmico:\n\

- cuando lo pulse - ¡el programa terminara! *thehelpbox.dialogTitle: Ayuda # FIN DE LAS ESPECIFICACIONES DE RECURSOS DEL EJEMPLO5 # #

el bo th Pulse aqui para salir:\n\

121


Puntos clave

El papel de la caja de herramientas La interfaz X Toollkit (herramienta X) se sitúa entre el programador de aplicaciones y las llamadas a las funciones Xlib, permitiendo a los programadores programar la computadora con un lenguaje de más alto nivel que las llamadas de bajo nivel de Xlib. Sustituye ventanas y sucesos por entidades más sofisticadas, widgets (elementos gráficos) y procedimientos de llamadas de retorno. X Toolkit consta de dos partes relacionadas: Xt Intrinsics y una herramienta en propiedad. Xt Intrinsics define una colección básica y estándar de funciones y estructuras de datos. Las herramientas en propiedad son más flexibles. son utilidades de programación potentes, ofreciendo cada una de éstas una apariencia distinta en la pantalla.

Programadores de la caja de herramientas A las herramientas pueden acceder por caminos diferentes dos categorías de programadores. Los programadores de aplicaciones utilizan los widgets ya existentes. En su trabajo, un widget es una "caja negra" que se puede usar, pero que no necesitan comprender. Los programadores de widgets crean y venden widgets, debiendo dominar los detalles internos de la creación y modificación de widgets.

Arbol de widgets El árbol de widgets es similar a la jerarquía de ventanas. La raíz del árbol de widgets es el widget Shell (Interfaz), asociado con un hijo de la ventana raíz. El nivel medio consta de widgets Composite (Compuestos) que reagrupan vanos widgets hijos para formar la interfaz gráfica de usuario. El nivel inferior está compuesto por los widgets Primitive (Primitivos) que no tienen hijos, tales como etiquetas, elementos de menú. y botones.

Clases de widgets Xt Intrinsics define cuatro clases de widgets básicos que pasan características fundamentales a las subclases de widgets de Intrinsics y a todas las clases de widgets de la herramienta. Son las clases de widgets Core (Núcleo), Composite (Compuesto), Constraim (Restricciones), y Shell (Interfaz). Las clases de widgets de la caja de herramientas se definen según las reglas para las subclases de widgets de Intrinsics. añadiendo reglas y características propias.

Las aplicaciones Motif Se pueden crear aplicaciones Motif siguiendo los siguientes pasos: incluir el archivo de cabecera Motif estándar; incluir el archivo de cabecera público para cada clase de widget usada; inicializar la herramienta; crear widgets: registrar llamadas de retorno, acciones, y gestores de sucesos requeridos; activar los widgets; e iniciar el procesamiento del bucle

Ciclo de vida de los widgets El ciclo de vida de los widgets es similar al ciclo de vida de las ventanas. Incluye su creación, activación, visualización y cancelación de ésta, y su destrucción.

122


Recursos Los recursos son elementos de datos con nombre cuyos valores pueden cambiar. Les permiten tanto al personal técnico como a los usuarios finales personalizar las aplicaciones. La herramienta recoge las especificaciones de recursos en el siguiente orden: primero, reconoce la lista de argumentos o parámetro varargs de la función de creación del widget; si aquí no se especifican valores, busca la especificación de recursos en la base de datos de recursos de visualización; finalmente, si no se especifica ninguno de estos valores, recoge el valor por omisión de los recursos de la clase del widget o superclase.

Llamadas de retorno Un aspecto esencial de la programación con herramientas es el uso de fimciones de llamada de retorno. Habitualmente, las aplicaciones construidas con la herramienta no solicitan directamente las entradas de usuario, pero si llaman a las rutinas de llamada de retorno apropiadas.

Widgets dinámicos Los widgets dinámicos son widgets transitorios; aparecen en la pantalla por un corto espacio de tiempo. Muchos widgets dinámicos son menús o cuadros de diálogo. Un cuadro de diálogo es un recuadro visualizado en primer plano que requiere de una entrada del usuario, muestra un mensaje, o ambas cosas.

123

Introducción al Sistema U N E

Capitulo 6

Introducción al sistema UNIX

Dverentes versiones de Unix

En términos generales se puede hablar de dos proveedores principales de sistemas Unix, uno es la compañía ATT que actualmente distribuye la versión System V , y el otro es la Universidad de California en Berkeley que actualmente distribuye la versión 4. SBSD.

Cuando se trabaja en un equipo con sistema Unix, se está en alguna de las dos versiones mencionadas en el párrafo anterior.

Ni ATT ni la Universidad de California construyen todo el equipo sobre el que se ejecuta el sistema Unix. Es decir, en la mayoría de los casos ellos sólo proporcionan el software. Cuando las compañías que construyen el hardware reciben el sistema, lo adaptan a su equipo en particular, y en general le agregan actividades que hacen que la versión original se convierta en la versión propia del fabricante. Esto es lo que sucede con el equipo de Hewlett-Packard (HP), que tiene un sistema operativo compatible con Unix llamado HP-UX.

Conceptos elementales sobre sistemas operativos El sistema operativo Unix se puede estudiar dividido en varias partes:

* manejo de la memoria, * manejo del procesador central, * manejo de los dispositivos periféricos y * manejo de la información.

Cada una de estas partes tiene algo que ver con el funcionamiento del equipo, por lo que se construyen los procedimientos necesarios para hacerlo, estos conforman lo que se conoce como el núcleo del sistema. A partir de é1 se construye una capa de programación que hace uso de los procedimientos más elementales. Sobre esta capa se crea otra que hace uso de la, o las, capas previas, y así sucesivamente.

Sistemas de un solo usuario

Los sistemas operativos monousuario son aquellos que en general se utilizan en las microcomputadoras, por ejemplo CP/M y MS-DOS. Los conceptos mencionados en el párrafo anterior se implantan en cualquier tipo de sistema operativo, aunque en los sistemas de tipo monousuario esto sea de manera limitada.

124

Introducción al Sistema UNLY

La diferencia principal entre un sistema monousuario y uno multiusuario es el uso del procesador central (CPU, Central Processor Unit). En el primer caso éste se dedica a atender uno o varios procesos de un sólo usuario (de ahí el nombre de monousuario).

Sistemas para varios usuarios

En este caso lo que se tiene es que un solo procesador central se dedica a atender a varios usuarios al mismo tiempo. Esto es, una sola computadora puede tener varias estaciones conectadas, y en cada una de ellas se puede solicitar la ejecución de diferentes procesos. El CPU utiliza técnicas adecuadas para dividir su tiempo y poner atención a todos y cada uno de los procesos que solicitan atención.

El manejo de múltiples usuarios implica mecanismos más elaborados de control sobre lo que forma el equipo de cómputo. Esto en general complica la construcción del sistema operativo (por supuesto que todo ello es transparente para el usuario). Al final lo que se tiene es un conjunto de actividades más amplio y más poderoso.

Sistemas de multiproceso En la actualidad el equipo de cómputo, por el lado de la electrónica, cada vez se vuelve más económico. Esto hace que cada vez más gente tenga sobre su escritorio una máquina, conocida como estación de trabajo (workstation). Muchas de estas tienen como sistema operativo Unix, un sistema de tipo multiusuario, en una máquina dedicada a un solo usuario. Para é1 esto le da la ventaja de que puede ejecutar varios procesos al mismo tiempo en su máquina. Aun más, si quiere incrementar su potencia de cómputo puede poner su máquina en red y tener acceso a otras máquinas como la suya, en las que también puede mandar a ejecutar procesos, de los cuales luego recibe los resultados.

125

Principios básicos

Capítulo 7

Principios básicos Sistema de almacenamiento En este caso el sistema de almacenamiento incluye los diferentes sistemas de archivos y los dispositivos que se tienen en el sistema.

Hay que recordar que el sistema de archivos está organizado de manera jerárquica a través de un árbol.

El directorio más alto es conocido como la raíz I o root. En é1 hay varios archivos y directorios que son importantes, como: /bin, Ietc, ltmp, Aib, lusr y ldev.

En algunas ocasiones en los directorios se encuentra el archivo READ.ME, el cual se puede revisar con órdenes como cat o more. En este archivo, en general, se encuentra información acerca del contenido del directorio, su fecha de liberación, cómo modificarlo, etc.

También se puede encontrar un archivo llamado Makefile o makefile, que tiene que ver con la manera como se genera la versión ejecutable de alguna, o algunas, de las órdenes que se incluyen en el directorio. Se sugiere no ejecutar el archivo de make, a menos que se esté completamente seguro de que eso es lo que se desea hacer.

Órdenes Las órdenes que ejecutan actividades específicas sobre el sistema y que se distribuyen de manera estándar cuando se instala un equipo, se encuentran contenidas en los directorios /bin y Iusrlbin. Las órdenes pueden ser programas o shells ejecutables.

Ya que las órdenes se tienen que buscar en dos directorios, es necesario que estos estén dados de alta en la variable de shell llamada PATH.

La razón por la que hay dos directorios donde se guardan las órdenes tiene que ver con la historia del desarrollo del sistema Unix. En el principio los discos donde se almacenaba la información eran de baja capacidad, lentos y caros. Así que en algunas instalaciones la configuración del equipo de cómputo tenía un disco de mediana capacidad, lento y no muy caro, complementado con un disco de baja capacidad, rápido y muy caro. En el disco más caro se tenía el directorio /bin y de él dependían las órdenes que se emitían más a menudo, y que por lo mismo tenían que viajar constantemente entre la memoria de la computadora y el disco. Las órdenes que no eran tan usadas se colocaban en el disco más barato bajo el directorio Iusrhin. Este esquema se ve repetido en varios de los otros directorios.

Cualquier usuario puede hacer programas o shells que al final pueden quedar como órdenes comunes del sistema. La secuencia de pasos que se sugiere para efectuar esto es:

126

Principios básicos

Verificar que la orden funcione adecuadamente y que reporte las causas de error en caso de que falle.

Instalar la documentación necesaria en el directorio que corresponda a los tópicos del manual, en particular a la primera sección del mismo -/usr/man/manl/nuevaorden-.

Mover el programa ejecutable al directorio más adecuado de los dos siguientes: Ibinlnuevaorden 0

/usrhin/nuevaorden.l.

Asegurarse de que el propietario de la nueva orden sea bin -UID 1-, y que el grupo sea también bin - GID I-.

Verificar que los permisos del usuario y del grupo sean para leer, escribir y ejecutar. Para los otros los permisos deben ser sólo de lectura y ejecución. Si la nueva orden necesita permisos especiales hay que encender los bits de SUID y de SGID.

Poner el código fuente de la nueva orden en el directorio que corresponde a dichos códigos, por ejemplo: /usr/src/cmd/nuevaorden.c.

También se deben poner, en el mismo directorio, los detalles apropiados del archivo del make para la nueva orden, como Makefle o makefile, y de ser posible algún archivo como el read.me que documente esta nueva orden.

Archivos temporales Muchos de los programas que están dentro del sistema generan estados intermedios antes de producir su resultado final. Estos estados intermedios, debido principalmente a su tamaño, no siempre se pueden conservar en la memoria de la computadora, por lo que es necesario enviarlos en forma de archivo temporal al disco. Los compiladores y los editores de texto son ejemplos de los programas que generan estados intermedios. Igual que en el caso anterior hay dos directorios donde se guardan los archivos temporales: /tmp y /usr/tmp.

Es importante verificar que estos directorios tengan todos los permisos (de lectura, escritura y ejecución) para todos los usuarios (propietario, grupo y otros).

Bibliotecas del sistema

Hay grupos de funciones que llevan a cabo tareas específicas. Estos grupos de funciones se pueden organizar en bibliotecas. Así se tienen bibliotecas de funciones matemáticas, bibliotecas de fonts, etc. Algunas de ellas son utilizadas por los compiladores o ligadores, otras por los procesadores de textos, etc. Dentro de los directorios /lib y /usr/lib se tienen varias bibliotecas de funciones.

Además el sistema proporciona una orden ( ar ) con varias opciones para crear, mantener y eliminar bibliotecas. Esto hace que el usuario pueda mantener actualizadas las bibliotecas con que cuenta gracias a la distribución y que también pueda generar sus propias bibliotecas.

Algunos de los archivos que se incluyen bajo estos directorios son: rutinas de apoyo al tiempo de ejecución para programas escritos en lenguaje C, las diferentes pasadas del ensamblador, las diferentes

127

Principios básicos

pasadas del compilador de C, las pasadas del compilador de FORTRAN, el programa atrun que es parte de la orden at, los programas asociados a la orden calendar, etc.

Usuarios

El objetivo principal del directorio íusr (íhome para HP-UX) es contener todos los usuarios del sistema, pero no hay restricción para que esto sea así obligatoriamente.

Además de los usuarios hay otros directorios bajo Iusr, esto son:

e

e

e

e

e

e

e

e

e

e

e

e

e

Iusríman contiene toda la documentación en línea del sistema.

íusrídoc contiene los documentos que describen a Unix.

íusríadm contiene archivos que tienen que ver con las operaciones administrativas.

Iusrldict contiene archivos que están relacionados con las órdenes de manejo de texto de los procesadores.

íusrígames contiene juegos.

íusríinclude contiene los archivos de definiciones que se incluyen como parte de los programas escritos en lenguaje C.

íusrípub contiene archivos públicos de diversas funciones.

íusrísrc contiene los archivos fuente de las órdenes del sistema, de las bibliotecas y de los juegos.

/usr/spool contiene varios directorios para guardar archivos temporales de una manera más segura, tales archivos son:

IusríspoolApd contiene los archivos que se van a mandar a la impresora.

íusríspooUuucp es una área que se usa para comunicarse a través de la orden uucp.

íusrIspooUmai1 contiene los archivos del correo entre usuarios.

íusríspooUat contiene las órdenes que están en espera de ser ejecutadas cuando les llegue el momento.

Administración En el directorio tetc se encuentran varios archivos de tipo admmistrativo, como:

e accton: archivo para iniciar el shell de contabilidad.

cron: programa para procesar la bitácora por tabla. -.

128

Principios básicos

ddate o dumpdate: archivo que contiene los tiempos y niveles de los dumps más recientes del sistema de archivos.

fsck programa para verificar la consistencia del sistema de archivos.

getty: programa que forma parte del proceso de logging-in.

group: contiene las especificaciones de los grupos existentes, y los usuarios que pueden usar la orden newgrp.

init o inittab: programa que controla la multiprogramación.

logmessage o ident: si existe, contiene el mensaje de identificación que se despliega antes del login.

mkfs: la orden para hacer sistemas de archivos.

mknod: la orden para hacer nuevos dispositivos.

motd: archivo de texto con el mensaje del día.

mount: orden con doble propósito, primero, indica qué sistemas de archivos están montados y segundo, monta sistemas de archivos.

mtab: archivo en forma de tabla que mantiene la orden mount para saber qué sistemas de archivos están montados.

passwd: principal archivo con detalles de los usuarios.

rc: archivo de shell que se ejecuta como última parte del proceso de inicialización para pasar el sistema a multiusuario.

shutdown: guión de shell para apagar adecuadamente el sistema.

termcap: archivo de texto con las características de las terminales.

ttytype: archivo de texto que especifica el tipo de terminal asignada a cada línea activa.

ttys: archivo de texto que especifica las líneas de terminales activas y su tasa de transmisión.

umount: orden para desmontar sistemas de archivos.

update: orden que vacía el contenido de la memoria al disco de manera regular. Esta orden está activa si el sistema funciona en modo multiusuario.

utmp: archivo que contiene una lista de los usuarios dados de alta actualmente en el sistema.

wall: orden para escribir a todos los usuarios.

129

Principios básicos

Dispositivos El directorio /dev contiene, por convención, todos los archivos especiales que representan los dispositivos que hay en el sistema (device $les). También contiene un archivo MakeJile, como cualquier otro directorio, para llamar a la orden mknod que crea los dispositivos. Fuera de las terminales de línea, en general, ningún otro dispositivo tiene acceso público.

Otros directorios y archivos El directorio /mnt se usa principalmente para montar dispositivos de permanencia temporal en el sistema, como los discos flexibles. Después del montaje, cualquier referencia a dicho directorio se dirige al dispositivo que representa.

El directorio Aost+found contiene los archivos que la orden fsck encuentra que pueden estar en mal estado al efectuar la verificación del sistema de archivos.

El archivo unix o vmunix contiene el núcleo del sistema que se carga como tercera etapa del proceso de arranque.

El archivo boot contiene el programa que se ejecuta como segunda etapa del arranque del sistema.

130

Encendido y apagado del Sistema

Capítulo 8

Encendido y apagado del sistema Encendido El encendido de una máquina con sistema Unix es totalmente dependiente del hardware -HW- de la misma. El arranque consta principalmente de tres pasos. El primero se da cuando se enciende, O se oprime el botón de reboot, de la máquina. En ese momento se lee el bloque cero del dispositivo de arranque, que en general es un disco duro incluido dentro del equipo, aunque no se descarta la posibilidad de hacer el arranque desde un dispositivo removible como una cinta o un disco flexible.

En dicho bloque se encuentra un programa especial, que es el primero que se ejecuta en la máquina y es muy dependiente de las características de la misma.

El segundo paso consiste en cargar el programa llamado boot que se encuentra bajo el directorio raíz. Este se llama desde el sistema de archivos y puede ser especificado por el usuario.

El tercer paso consiste en llamar a ejecución al programa unix, o vmunix, que también está en el directorio raíz. Este programa quedará residente en la memoria principal mientras esté encendido el sistema, es el que se conoce como núcleo.

Lo primero que se hace después de cargar el núcleo es una prueba para encontrar la totalidad de la memoria con que cuenta el equipo. Después de esto se arranca lo que es propiamente el primer proceso en la computadora, el proceso init, que existe como código binario en / e tcht i . Este se ejecutará en modo de superusuario.

Una de las primeras actividades de init es arrancar un shell sobre la consola para que el operador efectúe tareas de administración, tales como: poner la fecha, verificar la consistencia del sistema de archivos, reconfigurar la lista de las terminales en línea, etc.

El programa /etc/fsck es el que verifica la consistencia de los sistemas de archivos, la lista de los dispositivos de almacenamiento se toma de /etc/checklist. Los archivos que se sospeche que pueden estar cormptos se colocan en el dispositivo que corresponda bajo el directorio /lost+found. Debe haber un directorio /lost+found en la raíz de cada sistema de archivos montable. Si el sistema de archivos de root necesita ser reparado, fsck ejecuta las acciones necesarias, después de esto es necesario rearrancar el sistema.

Si se desea ejecutar operaciones que afecten archivos, primero hay que montarlos, ya que al tiempo de boot lo Único que está disponible es el sistema de root.

Cuando el operador da por terminada su actividad en el shell inicial, lo suspende para que init continúe su ejecución. El siguiente paso de init es pasar el sistema a modo multiusuario. Esto se hace fundamentalmente a través de dos etapas:

131


a> Operaciones que se hacen sólo una vez, como:

0 montaje de los sistemas de archivos que se requieran, arranque de los procesos permanentes de update y cron,

0 conservar los archivos importantes que se encuentren bajo el directorio /tmp, y 0 remover los archivos temporales que estén bajo ltmp.

b) Acciones que se ejecutan una vez, para cada línea que va a manejar una terminal que sea parte del servicio para multiusuario, tales como:

0 determinar el número y tipo de las terminales en línea, 0 inicializar las tasas de comunicación correctas, paridad, etc., e

iniciar los procesos de logging-in.

El programa init ejecuta las operaciones que se llevan a cabo una sola vez, guiado por el contenido del archivo Ietclrc.

Para las terminales se revisa el archivo Ietclttys, en el que se encuentra qué líneas de comunicación van a estar activas. Este archivo está organizado por renglones, el primer carácter del renglón indica si se va -1- , o no -O-, a colocar un proceso sobre la línea, el segundo carácter es una letra de código que representa las características del dispositivo, la parte restante del renglón es el nombre del dispositivo.

Si la línea de comunicación va a estar activa (tiene un 1 como primer carácter en el renglón que le corresponde en el archivo /etc/ttys), se manda ejecutar un proceso llamado Ietclgetty, que lleva como argumento el segundo carácter del renglón, y con los estándares de entrada, salida y error redireccionados al nombre del dispositivo. El proceso get0 inicia el modo de comunicación sobre la línea para el dispositivo que tiene asignado.

Si la letra de código que indica las características del dispositivo (en el archivo /etc/ttys) sólo representa la velocidad de transmisión, entonces en el archivo Ietclttytype se encuentra el tipo de dispositivo de que se trata y la línea de comunicación a la que está conectado, y en el archivo Ietdtermcap se encuentran todas las características de comunicación del dispositivo.

El proceso de inicialización concluye con un proceso getty en cada una de las terminales que están conectadas a la computadora y el proceso init activo pero en estado de espera. Es decir, init está en espera de que alguno de los procesos getty que arrancó (sus hijos) le envíen una seíial de que han muerto, para que éI los vuelva a generar.

Apagado Hay que ser cuidadoso al apagar una máquina con sistema Unix. El sistema perdería la información que maneja en la memoria si el sistema se apaga abruptamente. Esto podría hacer que el disco no se actualizara de manera adecuada, por lo que quedaría en un estado inconsistente. En general, el sistema proporciona una orden que sirve para verificar que todo esté en orden antes de apagar la máquina. Esta orden ejecuta los siguientes pasos:

a) Detener todos los procesos de login para que ya nadie entre al sistema.

132


b) Enviar un mensaje, cada cierto intervalo, a todos los usuarios que estén trabajando en el sistema, para prevenirlos de que se suspenderá el servicio.

c) Matar a todos los procesos, incluyendo los que se ejecutan de manera permanente como cron, que puede arrancar procesos en cualquier momento.

d> Ejecutar la orden sync para que los buffers de memoria copien su contenido al disco.

En algunas ocasiones la orden para detener el sistema, shutdown, acepta argumentos que le permiten ejecutar otras acciones, por ejemplo, hacer el reinicio del sistema.

133

Conexión y desconexibn de usuarios

Capítulo 9

Conexión y desconexión de usuarios

Conexión (logging-in)

Cuando no hay ningún usuario conectado a la computadora a través de una terminal, en la máquina se está ejecutando el proceso getty para esa terminal. Cuando el usuario intenta darse de alta, el proceso anterior se sustituye por el proceso login -/bidlogin-. Este proceso toma del usuario su nombre y su contraseña y los verifica, para saber si se le debe dar acceso al sistema.

Los datos de todos los usuarios que tienen acceso al sistema se conservan en un archivo llamado Ietclpasswd. Este archivo se organiza por líneas, es decir, cada una de ellas contiene los mismos campos (separados por el carácter:, dos puntos). Enseguida se describe cada uno de los campos que contiene el archivo:

nombre: el identificador del usuario, 8 caracteres como máximo.

passwd: contraseña cifrada del usuario.

uid: el identificador del usuario, entero de dos bytes como máximo.

gid: el identificador del grupo al que pertenece el usuario, dos bytes como máximo.

especial: campo para información dependiente de la instalación. Este campo lo ignora el proceso login. No debe contener caracteres dos puntos. Se sugiere que este campo no sea muy largo.

directorio domicilio: el directorio al que se envía al usuario al entrar al sistema.

shell: el nombre del programa que actúa como intérprete de comandos, el Bourne -/bidsh- o el C - Ibidcsh- .

Como primer paso, después de que se da acceso al usuario, se envía el mensaje del día -1etclmotd-, después se revisa el directorio donde está su correo, en caso de que se hayan recibido mensajes nuevos, se le envía un mensaje para indicarle que tiene correo -You have mail-.

También se da de alta una nueva entrada en el archivo Ietclutmp. ÉSta contiene el nombre del usuario, la línea a la que está conectado -1dev- y la hora de inicio de la conexión.

134

Conexión y desconexión de usuarios

Para cuestiones de admmistración se puede tener un archivo llamado /etc/adm/wtmp, con el mismo formato que el anterior, y en él se mantienen todas las conexiones y desconexiones que ha habido en la máquina. Cuando un usuario inicia su conexión, se genera una nueva entrada en el archivo (si existe). Para obtener los datos guardados en é1 se puede usar la orden ac.

LOS identificadores de uid y gid se ponen de acuerdo a lo que indican esos campos en el archivo passwd, para el usuario.

El siguiente paso es hacer que el directorio domicilio del usuario sea el que marca el archivo passwd.

Finalmente se ejecuta el shell que indica el séptimo campo del renglón que le corresponde al usuario en el archivopasswd.. Este shell ejecutará el guión del archivo .profile o .login (si es que los hay).

Desconexjón (logging-out)

La desconexión de un usuario es principalmente la eliminación del shell en el que está trabajando. Éste termina cuando recibe un carácter de fin de archivo -EOF-. Al finalizar envía al proceso que lo había creado una señal con su identificador de usuario (uid). El proceso que recibe la señal es inii, mismo que procede de la siguiente manera:

0 Determina qué usuario, y en qué terminal, ha dado de baja,

0 Actualiza el archivo /etc/utmp desactivando la entrada apropiada (la de la línea que se desconectó),

0 Actualiza el archivo /etc/adm/utmp agregándole una entrada con la fecha, la línea de la terminal, el nombre de conexión del usuario y una marca de que es un registro de desconexión,

0 Finalmente genera un nuevo proceso de getty para que atienda a la terminal.

135

Capítulo 1 O

El shell

El trabajo tradicional del shell es recibir las órdenes que digita el usuario e interpretarlas adecuadamente. Se espera que brinde al usuario un amplio rango de órdenes, permitiéndole configurar su interfaz de comunicación tanto como sea posible.

Existen dos programas de shell, el Bourne y el C. Enseguida se trata acerca de las características generales y los principios comunes a ambos.

Si se le pide al shell ejecutar una orden, tiene que saber en qué directorio se encuentra el programa o el guión (script) que la lleva a cabo. La variable PATH que es la que indica en qué orden se deben recorrer los directorios para encontrar el programa o guión que lleva a cabo la orden. Si lo encuentra y se trata de un programa binario el shell hace una llamada exec y otrafork. Si se trata de un guión, se genera un nuevo shell con la entrada redireccionada para leer del archivo donde está dicho guión. El shell anterior se queda esperando a que la orden termine de ejecutarse. En caso de que la orden haya sido terminada por un carácter &, no se espera a que el nuevo shell termine.

Cuando el usuario empieza a trabajar con el shell, tiene un conjunto de variables de ambiente definidas, algunas de ellas toman su valor al momento de ejecutarse el guión llamado .profile o .login. Es posible que el usuario cambie el valor de alguna de esas variables, sin embargo, para que el cambio tenga efecto es necesario volver a ejecutar el guión. Hay un par de órdenes que permiten ejecutar estos guiones en cualquier momento, éstas son: source y . (punto), por ejemplo:

% source .login $ . .profile

El shell de C ejecuta el archivo .logout, si existe, cuando el usuario da por concluida su sesión.

136

Control de usuarios en el sistema

Capítulo 11

Control de usuarios en el sistema Creación de un usuario Enseguida se describen los pasos necesarios para dar de alta un usuario. Aparte de estos hay que considerar otros aspectos, como el espacio de disco suficiente para contener la información del nuevo usuario.

Determinar el nombre (login name), el identificador -uid- y el grupo -gid- del usuario. El nombre y el identificador deben ser únicos. El grupo, en general, ya existe. Tanto el identificador como el grupo son números (enteros de 2 bytes).

Determinar los datos apropiados que identifiquen plenamente al usuario para introducirlos en el campo especial del archivo passwd.

Los datos anteriores se deben dar de alta en el archivo Ietclpasswd. Es posible que en la instalación haya más de una persona con derechos de acceso sobre tal archivo, por lo que se debe tener cuidado cuando se edite, para no entrar en conflicto si es que hay alguien más editándolo.

Si es necesario, también se debe editar el archivo Ietclgroup para dar de alta los grupos a los que se puede cambiar este usuario.

Hay que crear el directorio domicilio del usuario y dejarlo como propietario del mismo. También hay que cambiar el grupo del directorio para que sea aquel al que pertenezca el usuario. Después se pueden copiar los archivos por definición .login, .cshrc o .profile.

Es necesario crear el directorio donde el usuario va a recibir y enviar correo. Es posible que, dependiendo de la instalación, haya necesidad de dar de alta al usuario en los grupos de intereses específicos, y a ciertos directorios de correo entre máquinas.

Eliminación de un usuario Los pasos que hay que seguir para eliminar un usuario son:

Borrar la línea que le corresponde en letclpasswd.

Borrar cualquier referencia al usuario en letc/group.

Eliminar su directorio domicilio y todos los archivos que dependen de él.

Remover su directorio de correo y cualquiera de sus archivos en las colas de spool.

137

Control de usuarios en el sistema

Hay que tener cuidado con el número de UID del usuario que se elimina, ya que si se vuelve a asignar de inmediato, aún pueden haber archivos en el sistema, con ese níunero como identificador del propietario, por lo que el nuevo usuario estaría heredando cosas que no le pertenecen, y seguramente el sistema estaría manejando información inútil.

Grupos Todos los archivos y procesos dentro del sistema tienen dos identificadores: uno de usuario y otro de grupo. Para los procesos, el identificador de usuario y de grupo son heredados del proceso que los arrancó. En los archivos estos identificadores se heredan del proceso que los crea. Durante una conexión normal, los identificadores de usuario y de grupo se toman del archivo Ietclpasswd.

El superusuario puede hacer las llamadas al sistema setuid y setgid para poner los valores de uid y gid que le convengan.

Los grupos dentro del sistema se refieren al aglutinamiento que se da en las organizaciones, de manera natural o por cuestiones de trabajo. Dentro de la computadora esos grupos se representan con números, tanto en el archivo Ietclpasswd, como en Ietclgroup.

El contenido del archivo /etc/group está organizado por renglones, cada uno de ellos tiene los mismos campos, separados por el carácter dos puntos, estos son:

nombre

contraseña

gid, entero de hasta dos bytes

los nombres de los usuarios que pueden estar en é1

El último campo se refiere a los usuarios que bajo su conexión original pertenecen a un grupo, pero que desean emitir la orden newgrp para cambiar de grupo. Si su nombre clave está en la lista del grupo al que desea cambiar, la orden newgrp efectuará el cambio, de otra manera, seguirá en el mismo grupo.

Cuando el superusuario crea archivos, estos tienen los identificadores de usuario y de grupo de root. Si los nuevos archivos van a pertenecer a usuarios, hay que cambiarles los identificadores, la orden chown cambia el del usuario, y chgrp cambia el del grupo.

La utilería umask permite otorgar, por omisión, los permisos con los que se crean los archivos nuevos. El argumento son tres números octales, el primero define los permisos del propietario, el segundo y tercero definen los permisos del grupo y del público. Los bits encendidos definen los permisos que no se dan.

138

Dispositivos

Capítulo 12

Dispositivos

En Unix los dispositivos caen en dos categorías generales, de caracteres en secuencia y estructurados en bloques. El sistema intenta que los dispositivos serie aparezcan como archivos ante los usuarios, mientras que los dispositivos de bloques se accesan a través de solicitudes al sistema de almacenamiento.

El directorio de dispositivos da a cada uno de ellos un nombre y un nodo-i. En éste hay un campo que especifica que es un dispositivo y de qué tipo es, carácter o bloque. También contiene información particular del dispositivo, a través de dos números, el mayor y el menor. El número mayor indica el tipo del dispositivo de que se trata, el número menor indica, para el tipo que marc6 el número anterior, de qué instancia se trata. Esta información la recibe el núcleo del sistema y basado en ella efectúa las operaciones de entraddsalida.

Generalmente los dispositivos están bajo el directorio /dev, aunque esto no es obligatorio.

Agregar un dispositivo a Unk Si se intenta crear un dispositivo diferente de los que por definición tiene dados de alta el sistema, se tendrán muchos problemas, pues esta tarea es muy dependiente de la instalación y de los fabricantes de dispositivos.

Se pueden dar de alta nuevos dispositivos, pero el código que los controla debe estar ya dentro del núcleo del sistema. El número mayor del dispositivo se refiere a la parte de software del núcleo que lo controla, y el número menor a una instancia del tipo de dispositivo.

Para saber qué tipos de dispositivos hay en la instalación se puede dar la orden:

Is -1 /dev

que entrega una lista con todos los archivos bajo el directorio /dev. Las líneas que inicien con una c se refieren a un dispositivo de tipo carácter, las que inicien con una b a un dispositivo de tipo bloque.

La orden para dar de alta un nuevo dispositivo es:

/etdmknod /dev/newdev c 5 7

Esta orden crea un dispositivo nuevo en el directorio Idev, su nombre es newdev, es de tipo carácter, su número mayor es 5 y su número menor es l.

.

139

Dispositivos

~~ ~

Dispositivos estructurados por bloques (sistemas de archivos)

Se puede crear un dispositivo de bloque, después crear un sistema de archivos sobre 61 y finalmente montar el sistema de archivos sobre Unix.

Para crear el dispositivo se da la orden:

/etdmknod /dehombre b mayor menor

Si el nuevo dispositivo es un disco, seguramente necesitará ser formateado, para esto el distribuidor debe proporcionar las herramientas adecuadas. Después hace falta introducir al dispositivo información propia de Unix para crear sobre é1 un sistema de archivos, esto se lleva a cabo con la orden:

/etc/mkfs /dev/nombre 4567

Esta orden hace todo el proceso de inicialización que necesita el dispositivo, como el superbloque, el directorio raíz, la reserva de espacio para los nodos-i, el espacio de datos, etc. También puede efectuar tareas específicas, a petición del usuario, como: distancia entre sectores consecutivos de un archivo en el dispositivo.

El dispositivo debe tener un directorio llamado /lost+found, el cual es usado por la ordenfsck.

El dispositivo ya está listo para montar sobre él parte del sistema de archivos, para esto hay que dar la orden:

/etc/mount /dev/nombre /directorio

Dispositivos crudos y estructurados por bloques Es muy común que para los dispositivos del sistema de archivos se tengan dispositivos de series de caracteres (conocidos como crudos), y dispositivos estructurados por bloques. Esto da la facilidad de leer secuencialmente el dispositivo de bloque, lo cual resulta más eficiente en algunas circunstancias. Los dispositivos usualmente vienen en pares, uno de bloque y otro de carácter. Tienen los mismos nombres, pero se les agrega una letra, por ejemplo una r, para diferenciarlos. Así se tiene /dev/disc para un dispositivo de bloque y /dev/rdisc para un dispositivo crudo. La r se agrega por raw (crudo).

Dispositivos de caracteres En este tipo de dispositivos se incluyen terminales, consola principal, impresoras y manejadores de cinta magnética. Se crean a través de la orden:

/etdmknod/dev/nombre c mayor menor

En este caso el número mayor corresponde al número de multiplexor al que está conectada la terminal, el número menor indica cual es la línea de conexión. Las terminales en general tienen nombres con el

140

Dispositivos

prefijo tty y terminan con un par de números que indican de qué terminal se trata, aunque este tipo de nomenclatura no es obligatoria.

Existen algunos dispositivos especiales que no representan ningún periférico en particular, los más comunes son:

Idevltty cuando se utiliza este dispositivo, da las características de la terminal en la que se invoca. Sirve para averiguar la configuración de la terminal en la que se está trabajando.

/devlnull cuando se escribe sobre este dispositivo, todo lo que se le envía se pierde en el vacío. Es útil para capturar mensajes de error que no se desea que aparezcan en la pantalla. Si se lee de este dispositivo siempre regresa un código EOF.

Idevlmem es un dispositivo de caracteres con información que se refiere al programa que está actualmente en memoria. Si se conoce cómo está cargado en memoria el programa al tiempo de ejecución, se puede leer su contenido usando el adb.

Idevlkmem es un dispositivo de caracteres que hace referencia a la memoria del núcleo del sistema operativo. Este dispositivo es usado por órdenes tales como ps.

La características de las líneas series se pueden configurar usando las órdenes stty del shell, o ioctl de las llamadas al sistema. Las características que se pueden cambiar son: velocidad de señalización (baud rate), paridad, número de bits de arranque y de parada, etc.

14 1

Sistema de archivos y su mantenimiento

Capítulo 13

Sistemas de archivos y su mantenimiento

En esta parte se tratan aspectos relacionados con las tareas que el administrador tiene que llevar a cabo sobre el sistema de archivos. Algunas de ellas son actividades rutinarias, otras son explicaciones de cómo funciona el sistema de archivos.

Respaldo y recuperación de discos En cualquier instalación donde se trabaje con discos fijos se debe tener la precaución de mantener respaldos; principalmente por dos razones: la primera es que el dispositivo físico puede fallar en cualquier momento, la segunda es que algún usuario puede necesitar una copia, aunque sea vieja, de alguno de sus archivos.

Hay varias formas de respaldar y restablecer discos en Unix. Cada una tiene beneficios y desventajas, y es una buena decisión usar diferentes métodos en distintas fechas para diferentes discos.

Las drdenes dump y restor

La orden dump toma sus datos de un dispositivo fisico, más que de uno lógico. Obtiene la información elemental de los nodos-i del dispositivo crudo, y a partir de estos localiza los nombres y posiciones de los archivos, cuáles de estos son directorios y cuándo se modificaron por última vez. Con estos datos se puede respaldar todo el sistema de archivos del dispositivo o aquellos que se hayan modificado a partir de la última fecha en que se hizo el respaldo.

Como la orden dump requiere leer del dispositivo crudo, sólo la puede ejecutar un usuario con privilegios como root.

Hacer un vaciado completo del sistema de archivos puede tomar mucho tiempo, por esta razón es más recomendable hacer vaciados por niveles, es decir, hacer un vaciado completo y los que le sigan después se hacen sólo sobre los archivos que se modificaron después del vaciado previo.

Otro factor importante es el número de cintas de respaldo con el que se cuenta, ya que esto influye sobre la frecuencia y los niveles con los que se hace el vaciado.

La orden que se usa para restablecer lo que contiene una cinta de vaciado es restor. Esta orden también se puede utilizar para mover un sistema de archivos completo de un disco a otro, o para reemplazar el

142


sistema de archivos después de reformatear el mismo dispositivo. Esta orden también sirve para restaurar archivos individuales que los usuarios soliciten.

La orden tar

Esta orden se usa principalmente para hacer la transferencia de una rama completa del directorio a un dispositivo de tipo serie, como una cinta o un disco flexible. Una de las condiciones para hacer el acceso a los archivos es que el que emite la orden tenga permiso para accederlos. Esta orden toma los datos para ubicar archivos y directorios de la estructura que hay sobre el dispositivo. Cuando la orden tar extrae archivos del dispositivo les pone una marca, esto hace que sea posible extraer, en fecha posterior, todos los que no estén marcados. Los argumentos que se le dan a la orden tar son los que indican la dirección de transferencia de información de o hacia el dispositivo.

La orden dd

Esta orden hace una copia directa, de dispositivo a dispositivo, entre dos dispositivos de tipo serie, o entre archivos, a los cuales se les especifica un tamaño de bloque para la transferencia. Cuando se usa la orden dd se desea copiar el disco tal como está a la cinta magnética. El usuario que emita esta orden debe tener los privilegios necesarios para hacer este tipo de acceso a los dispositivos.

Al hacer un respaldo del sistema, por cualquiera de los medios mencionados, se debe tener cuidado de que el sistema de archivos esté en estado estable. Es decir, que no se estén modificando archivos, porque esto haría que no se tuviera una copia fiel del estado actual del sistema. Aunque esto puede hacer que el rendimiento de la máquina se degrade.

Transferencia de archivos entre sistemas Se mencionan dos interfaces en las cuales las máquinas están conectadas por medio de un cable serie.

La orden cu permite a un usuario en una máquina conectarse a otra a través de la línea serie. La máquina local no debe tener un proceso de login en el puerto que hace la conexión a la otra máquina. La máquina remota debe tener un proceso activo de login en ese puerto. En general este método es temporal.

La orden uucp permite que la conexión serie se use para la recepción de archivos y correo de manera automática entre los sistemas ligados. La orden uucp conserva una copia del archivo a transferir, y se da de alta en el sistema remoto con el nombre uucp. Por esto todos los permisos de acceso para los archivos en la máquina remota deben ser relativos a ese nombre.

La orden uux permite la ejecución de órdenes en una máquina remota, esta orden también se da de alta en la máquina remota como uucp y luego emite la orden que se quiere ejecutar.

143


Ocupación y uso del sistema de almacenamiento

La orden du

Esta orden, sin argumentos, entrega un resumen del espacio de disco usado, medido en bloques, a partir del directorio actual, o si se le indica un directorio, da el espacio que ocupa dicho directorio.

La orden quot

Esta orden puede recorrer el conjunto completo de los archivos del sistema, revisando quién es el propietario de cada archivo, y sumando los tamaños de cada uno, a su respectivo propietario. Si no se le dan argumentos a la orden, se obtiene una lista con el espacio de disco ocupado por cada usuario. Hay que tener en cuenta que esta orden puede ser de ejecución muy lenta.

La orden df

Esta orden da la cantidad total de espacio libre en el dispositivo indicado, o por omisión, todos los dispositivos involucrados en el sistema de archivos.

Bits especiales de acceso a los archivos Además de los nueve bits usados para manejar los permisos de acceso a los archivos -lectura, escritura y ejecución para propietario, grupo y otros-, hay otros tres bits con significado especial.

El bit de SUID

En Unix hay varios archivos, como passwd, que sólo pueden ser modificados por usuarios privilegiados. Sin embargo, hay ocasiones en las que los usuarios comunes necesitan hacer cambios a algunos de esos archivos, por ejemplo, cuando quieren cambiar su contraseña. Esta actividad se lleva a cabo a través de la orden passwd, que está disponible para cualquier usuario. Todas las órdenes que se ejecuten dentro del sistema tienen como identificación del usuario efectivo al que emitió la orden. De esta manera se puede revisar si al usuario efectivo le está permitido, o no, efectuar alguna actividad. Si hay una orden que está disponible para todos los usuarios, y que necesita tener acceso a archivos que no le pertenecen, el propietario de la orden debe encender el bit de SUID (set user id). El bit de SUID se guarda junto con los bits de permisos de acceso a los archivos. Este puede ser encendido o apagado por el propietario del archivo. En caso de ser un programa ejecutable, este bit permite al ejecutante que el usuario efectivo a tiempo de ejecución sea el del propietario del archivo, lo que permite al ejecutante tener acceso a los archivos con todos los privilegios que tendría el propietario.

La orden para hacer el cambio del estado del bit de SUID es:

chmod u+s archivos

Puede haber peligros para los archivos de root que tienen encendido su bit de SUID. Si se les deja encendido accidentalmente el bit de escritura, entonces cualquier usuario puede escribir en éI un

144


programa que después se ejecutará con permisos de superusuario. Otro puede ser que si el programa tiene una salida al shell, este tendrá privilegios de superusuario.

El bit de SGID (super user group id) Este bit es similar al de SUID, pero hace que los permisos de ejecución de un programa sean los mismos que tiene el grupo al que pertenece el propietario del archivo que se está ejecutando. Esta característica no es tan peligrosa como la anterior, ya que muchas de las operaciones requieren tener identificación de superusuario, independientemente de la identificación del grupo actual. La orden para encender el bit de SGID es:

chown g+s archivos

El bit pegajoso (sticky)

En ocasiones, alguno de los programas ejecutables se pone a funcionar muy a menudo, por lo que el hecho de perder su imagen de memoria y luego volverla a crear cuesta mucho, en cuestión de tiempo y espacio. En esos casos es mejor conservar la imagen de memoria, para hacer que esto ocurra se utiliza el bit pegajoso. Esto es, si un programa ejecutable tiene encendido su bit pegajoso, en el momento de terminar no se pierde su imagen de memoria, esta se conserva durante un lapso hasta que se vuelva a utilizar.

Sistema de archivos

Estructura del disco Los discos están divididos en bloques de 512 bytes. Todo el disco está dividido en bloques del mismo tamaño. El primer bloque contiene el sector de boot. El resto de bloques contienen sistemas de archivos. La división del cuerpo del disco entre varios sistemas de archivos se determina por el núcleo del sistema, y se puede hacer que un solo dispositivo fisico se vea como varios discos virtuales para el usuario.

Cada sistema de archivos consiste de un superbloque, que contiene detalles del tamaño del sistema de archivos, el número máximo de archivos, etc., una área de nodos i y una área de bloques de datos. Estos se inicializan utilizando la orden mkji La área de nodos i es de tamaño fijo.

Directorios Los directorios contienen una lista de los nombres de los archivos y sus correspondientes números de nodos i, como no contiene el número del dispositivo, el archivo debe estar en el mismo disco que el directorio, la excepción pueden ser los dispositivos montados.

Nodos i

145


El nodo i es una estructura de datos a través de la cual se hace el manejo del los archivos en el sistema. Los campos del nodo i incluyen áreas para: los permisos de acceso al archivo, el número de ligas con otros archivos, los valores numéricos del UID y el GID, el tamaño, en número de caracteres, del archivo y trece direcciones de bloques en el disco.

Dispositivos de disco por bloques y crudos Para cada dispositivo fisico en el sistema Unix hay un par de archivos asociados, uno para el acceso por bloque y otro para el acceso serie, o crudo. Tradicionalmente la versión serie tiene el mismo nombre que la de bloque, pero va precedida por una letra r.

Banco de buffers

Todas las operaciones de entraddsalida tiene lugar a través de un banco de buffers que maneja el núcleo del sistema. El banco es un mecanismo complicado que se diseííó para minimizar el tráfico del disco, y permite compartir buffers, siempre que sea posible, entre diferentes procesos.

Otras órdenes de mantenimiento del sistema de archivos

Algunas de las órdenes más importantes que el administrador debe tener presentes son:

jick: revisión y corrección del sistema de archivos.

ncheck: da el número de nodo i, nombre y propietario de archivos en un dispositivo.

clri: esta es una orden peligrosa y debe ser usada sólo por expertos. Reescribe el contenido de un nodo i, el sistema de archivos se debe desmontar, se debe determinar el número del nodo i, luego se limpia y finalmente se ejecutafsck para limpiar el sistema de archivos.

jidb: debug del sistema de archivos. Este también es para expertos, sirve para reparar discos, el usuario debe estar familiarizado con la estructura cruda de los discos.

sync: permite sincronizar el contenido del disco con las actualizaciones que sólo están en la memoria.

Las órdenes mount y umount

Para que un dispositivo se pueda montar sobre el sistema de archivos debe ser formateado y luego inicializado con la orden mkfs.

Si se monta un dispositivo intercambiable, como un disco flexible, se puede acceder su contenido desde el sistema de archivos.

Para efectuar el montaje se utiliza la orden:

/etc/mount /dev/floppy /mnt

146


~~~~ ~ ~ ~

donde /dev/floppy es el nombre del dispositivo y /mnt es el directorio bajo el cual se monta.

El disco flexible se debe desmontar con la siguiente orden antes de removerse:

/etchmount /dev/flopy

La orden:

/etdmount

s i n parámetros da una lista de los sistemas de archivos montados en ese momento.

147

Consideraciones de rendimiento

Capítulo 14


El sistema operativo Unix es un complejo mecanismo de multiproceso, con técnicas muy elaboradas para manejar la memoria, el cpu y los demás dispositivos. Una de las tareas más delicadas del administrador es supervisar el funcionamiento del sistema para poder ajustar sus parámetros, y que de esta manera se tenga un mejor funcionamiento del mismo. Esto redundará en tiempos de respuesta más efectivos para los usuarios y ayudará a seleccionar más adecuadamente las mejoras de hardware. Enseguida se tratan algunas de las órdenes que el sistema proporciona para monitorear su comportamiento.

Órdenes estúndares

Orden iostat

Esta orden debe dar detalles del tráfico hacia el almacenamiento de disco y de cinta magnética. Al ejecutar la orden se obtienen datos presentados por columnas, que pueden comprender lo siguiente: el rendimiento del disco, evaluado en número de transferencias por minuto, los milisegundos por búsqueda (seek), y los milisegundos por transferencia. Estos datos se evalúan desde el arranque del sistema y en intervalos de segundos que se dan como parámetros a la orden. También se obtiene el tiempo de procesador que se ha gastado en las cuatro categorías siguientes: user, nice, system e idle.

Si la orden se ejecuta con el parámetro -i, además de los datos anteriores se obtiene el porcentaje del tiempo durante el cual el procesador ha estado esperando que se satisfaga una solicitud de entraddsalida y el porcentaje de tiempo durante el cual la entraddsalida ha estado activa.

El parámetro -t da la actividad de la terminal, en promedio de caractereshegundo, así como la información anterior.

Dado que esta orden es muy dependiente del hardware, es necesario verificar que haya sido proporcionada con el sistema y la documentación que indique exactamente cómo funciona,

Orden sa

Efectúa la contabilidad de las órdenes ejecutadas a través del shell. La contabilidad se inicia usando:

/etc/accton

en el archivo /etc/rc, que se ejecuta al pasar el sistema a multiproceso. Si la orden se ejecuta exitosamente, entonces el sistema guardará para cada proceso: su nombre, el nombre del usuario que lo ejecutó, el tiempo de procesador usado y el tiempo que pasa entre el inicio y el fin de la ejecución. Este

148


archivo puede crecer muy rápidamente en algunos sistemas por lo que es importante vigilarlo. El análisis del contenido del archivo se lleva a cabo a través de la orden sa, para ver las diferentes opciones de funcionamiento de ésta se sugiere consultar el manual. Una de las opciones permite conservar un archivo con un resumen de las órdenes emitidas y los recursos utilizados. Todos los datos que se conservan son: nombre de la orden, tiempo de proceso del usuario, del sistema, tiempo transcumdo (elapsed), tiempo de inicio, identificación del usuario, identificación del grupo, uso de la memoria, y nombre de la terminal desde la que se emitió la orden.

Orden ac

Esta orden es para la contabilidad de los tiempos de conexión al sistema. Si existe el archivo /usr/adm/wtmp, cada login y logout será grabado, con su hora respectiva, nombre del usuario, terminal usada, etc. El archivo wtmp debe ser procesado regularmente ya que puede crecer demasiado.

La orden ac permite analizar la información almacenada en el archivo /usr/adm/wtmp, se sugiere consultar las diferentes opciones en el manual.

Consideraciones generales del rendimiento del disco

El disco es uno de los dispositivos más importantes del sistema Unix, pero muchas veces también es un cuello de botella, por lo que cualquier esfuerzo por mejorar su comportamiento tiene beneficios sobre la instalación. Uno de los objetivos más importantes es minimizar el movimiento de la cabeza lectora entre las transferencias de datos. Como se puede ver del resultado de una orden iostat, el tiempo de búsqueda es generalmente mayor que el de transferencia.

149

Seguridad en los sistemas Unix

Capítulo I 5

Seguridad en los sistemas U n k

Cuando se habla de seguridad dentro del ambiente Unix, a menudo se oyen comentarios de personas no bien informadas, que dicen que el sistema no es seguro. La verdad es que Unix es bastante seguro cuando se maneja correctamente.

Permisos sobre archivos Todas las órdenes, o sea todos los archivos bajo los directorios /bin y /usr/bin deben tener modos de acceso 771 para los archivos binarios y 775 para los guiones de shell. Los permisos del grupo se deben poner de tal manera que los usuarios con permiso para cambiarse al grupo del adrmnistrador del sistema puedan efectuar cambios sin necesidad de tener estatus de superusuario. De otra manera los modos deben ponerse cono 71 1 y 755 respectivamente. Si la ejecución de un guión no requiere permiso de lectura, se le debe colocar el permiso 77 l .

No debe haber ningún archivo propiedad de root con permiso público de escritura.

Directorios como /bin no deben tener permiso público de escritura.

Ninguna orden que tenga un escape hacia el shell debe ser propiedad de root con el bit de SUID encendido. Si por alguna razón esto es inevitable, se debe arreglar el código para que se actualice el UID efectivo, antes de hacer el escape.

Se deben vigilar los permisos que se dan por omisión cuando se crea un archivo, esto depende del ambiente en el que se esté trabajando. El valor que sé de a la orden umask debe reflejar las restricciones del medio.

Acceso a los dispositivos No debe haber permiso público de acceso a los dispositivos crudos del sistema de almacenamiento. Cualquier orden que sea accesible por usuarios comunes, pero que requiera acceso a un dispositivo crudo, debe ser un archivo con los bits de SUID o SGID encendidos y cuyo propietario tenga acceso a dicho dispositivo. Puede haber casos especiales de dispositivos fuera del almacenamiento general con permisos legales de lectura y/o escritura.

No debe haber acceso a /dev/mem o a /dev/kmem.

El acceso a la orden mount y a los dispositivos montables debe ser restringido.

-

150

Seguridad en los sistemas U n h

Otros puntos generales

Las contraseñas importantes se deben cambiar frecuentemente y deben ser conocidas por un grupo reducido del personal de sistemas. Se deben prohibir los logins sin contraseña sobre líneas externas y redes.

Puede haber un programa llamado .secure en el directorio domicilio del usuario, que el proceso normal de login arranca cuando se está tratando de establecer una conexión. Este programa es escrito por el usuario y contiene preguntas que sólo é1 conoce, de tal manera que siempre se está seguro de que sólo el sistema puede tratar de averiguar la clave y la contraseña de usuario.

La trayectoria de búsqueda para los usuarios a los que se les permita usar la orden su debe incluir el directorio actual al final.

Es buena política minimizar el uso de los privilegios como superusuario. La orden su se debe usar sólo cuando sea necesario. Se deben efectuar todas las tareas que sean posibles, a través de bin o del grupo de sistemas.

Otro punto importante de seguridad son las cintas de respaldo del sistema. Es claro que toda la información del sistema está almacenada en esas cintas, y si se pierden o roban se pueden restaurar en cualquier otra máquina. Por lo tanto, es importante conservarlas en un lugar seguro.

151

Algunas órdenes importantes para los Administradores

Capítulo 16

Algunas órdenes importantes para los administradores

Se revisa un par de órdenes de propósito general, para el mantenimiento de paquetes de programación que involucren un número de archivos de programas fuentes y de datos. También se revisa una orden que es un lenguaje de procesamiento y reconocimiento de patrones.

Orden make

Esta orden es útil para automatizar el mantenimiento de programas ylo archivos cuya integridad depende de grupos de archivos que se deben combinar de alguna manera para crear el programa.

Cuando se tiene un programa muy grande escrito a base de módulos y es necesario hacerle una modificación, el usuario puede, a través de la orden make, recompilar todos los módulos que dependen de la modificación.

Las acciones que lleva a cabo make se guían por las siguientes condiciones:

La fecha en que fue creado el archivo. El sistema compara las fechas de modificación de dos archivos y a través de ello determina cuál se modificó más recientemente.

Es necesario que el programador pueda estipular las dependencias del programa que resulte a partir de los archivos que lo constituyen.

La programación de make entiende ciertas dependencias importantes que van implícitas. Por ejemplo, que un archivo .o se genera a partir de otro de tipo .c.

Por omisión el programa make espera encontrar, en el directorio actual, un archivo llamado makefile (o Makefile) que contiene los detalles del programa que se puede construir y a partir de qué componentes.

Sistema de control de código fuente

Esta es una herramienta de programación, que al igual que make, puede parecer un lujo no esencial, hasta que se usa. Básicamente, el SCCS (Source Code Control System) permite al administrador conservar todos los archivos de respaldo de un conjunto importante de programas tal como se crearon, y darles mantenimiento.

la.

152


El sistema es capaz de mantener un archivo base, de una versión particular del código, con una lista de los cambios que se le han hecho para la representación actual. Esta información y ciertos datos administrativos se conservan en lo que se conoce como un s-file. La información adnunistrativa generalmente contiene cosas como:

0 las fechas de las diferentes versiones

0 el nombre del usuario que hizo cada versión

0 comentarios que acompañan a cada versión

0 una lista del personal elegible para hacer modificaciones

0 varios datos de verificación como el checksum.

El SCCS prueba su utilidad en proyectos grandes donde trabajan varias personas. En este caso, previene la edición de archivos que ya se están editando, conserva respaldos de todas las versiones y permite al personal tomar versiones con las que puede experimentar, s in afectar el código que ya funciona.

Hay muchas versiones del SCCS, en todos los casos lo más recomendable es ver la documentación que proporciona el distribuidor para saber exactamente qué se puede hacer.

Las órdenes más comunes que incluye esta herramienta abarcan actividades tales como: crear archivos de SCCS, o s-files, acceder a un archivo que está en formato de SCCS, guardar un archivo que estaba en formato de SCCS y que se accedió para modificarlo, incluir más usuarios en la lista de SCCS, detener la edición de un archivo, establecer el número de versión, etc.

A WK

Aunque propiamente no es una orden para la adnunistración, es una herramienta de tipo general que simplifica algunas de las tareas del administrador. Esta orden está diseñada para ejecutar operaciones sobre archivos que constan de un registro por línea, con los campos de los registros separados por algún carácter.

Awk es un editor guiado por sintaxis para seleccionar registros particulares, y un intérprete de proposiciones al estilo del lenguaje C para trabajar sobre los primeros. Las expresiones de selección pueden usar operaciones aritméticas y expresiones de caracteres. Un programa simple de awk queda de la forma siguiente:

expresión de selección { instrucciones

Además de esto, hay una sección opcional al inicio del programa que sirve para incializar, y una sección de conclusiones al final. Un programa en awk queda como sigue:

BEGIN {instrucciones de inicialización } expresión de selección {instrucciones }

^(" END {instrucciones finales}

153


Programas para la bitácora de procesos

Continuamente los administradores del sistema tienen la necesidad de ejecutar programas bajo bitácora, de manera regular. Por ejemplo, ejecutar procesos en las primeras horas de la noche, o funciones de contabilidad durante los fmes de semana, etc. Hay dos órdenes en Unix que ayudan a ejecutar este tipo de tareas, la primera es cron, y la segunda es at. Con cron se pueden ejecutar los procesos de manera periódica, y con at se puede ejecutar una sola vez un proceso en una fecha determinada.

La orden cron revisa una bitácora que está guardada en el archivo lusrtliblcrontab, cada línea de este archivo representa un evento que ocurre de manera regular, los campos de esta línea están separados por espacios blancos y cada uno de ellos representa: los minutos dentro de la hora -0 a 59-, la hora del día -0 a 23-, el día del mes -1 a 31-, el mes -1 a 12-, el día de la semana -l=lunes, 7=domingo- y la orden que se va a ejecutar en esa fecha. Los campos pueden tener un asterisco, lo que representa cualquier valor, un entero, o una serie de valores o rangos separados por comas y dentro de paréntesis cuadrados.

Una actividad que se lleva a cabo regularmente por medio de la orden cron es la ejecución de la orden calendar, busca un archivo central como /etc/calendar y archivos individuales como $HOME/calendar, con líneas que contengan las fechas de hoy o de mañana, y envía a los usuarios un mensaje de correo que consiste de esa línea completa. Así, uno de esos archivos que contenga la línea:

Oct 4 Cordonazo de San Francisco

ocasionará que un mensaje conteniendo esa línea se reciba el tres y cuatro de octubre. El programa es suficientemente listo como para ignorar los fines de semana y para enviar los mensajes por anticipado, si se atraviesa uno de ellos.

La orden at sirve para ejecutar una sola vez un programa en un tiempo futuro. La forma general de esta es:

at hora fecha archivo

Las órdenes a ejecutarse se guardan en un archivo en el directorio IusrIspooYat, y se preceden por órdenes que inicializan el ambiente a lo mismo que se tenía cuando se emitió la orden. Es necesario que la orden atrun se ejecute regularmente (cron la activa cada cinco minutos, por ejemplo), ya que ésta es la que revisa los guiones que esperan en IusrIspooYat.

154

Bibliografia

X Window System Program Design and Development Steven Mlkes Addison Wesley 1994.

MotifProgramming Manual Southerton Alan McGraw Hill 1992.

Programming with the X Window System Toolkits John Wiley & Sons Addison Wesley 1991.

HP-UX System Administration Tasks HP 9000 Series 700 I 800 Hewlett Packard Company HP-UX Release 1 1 .O

Solaris System User Administration Sun Microsystems, Inc. Release 2.3

Como usar UNIX Sistema V, versi6n 5.0 Megabyte Editorial Limusa S.A. de C.V.

HP Visual User Environment User 'S Guide Series 700 I 800 Hewlett Packard Company Release 3.0

UNIVERSIDAD AUTONOMA METROPOLITANA148.206.53.84/tesiuami/UAM3344.pdf · mrroauccron Introducción X...

Documents

Transcript of UNIVERSIDAD AUTONOMA METROPOLITANA148.206.53.84/tesiuami/UAM3344.pdf · mrroauccron Introducción X...