4 bits blog

Si alguna vez habéis tenido que programar algo para funcionar sobre la consola de Linux, a lo mejor os habría gustado poder colorear la salida, como hacen la mayoría de los programas de la consola de Linux.

Pues si vuestra consola admite colores ANSI (casi todas lo hacen, incluso la de Windows), lo tenéis muy fácil ya que mediante unas cadenas de escape se pueden cambiar los colores. Estas cadenas siguen un patrón del tipo:

<ESC>[{attr1};...;{attrn}m

Donde attrX es un código numérico que determina una característica del texto (como subrayado), el color del texto y el color del fondo de éste. Estos código están definidos y se pueden consultar en esta web que contiene las cadenas de escape ANSI.

De este modo, si se quiere cambiar el color del texto, por ejemplo en un programa en C, se haría lo siguiente:

printf ("\e[32m Soy de color verde\n");
printf ("\e[0m Vuelvo a ser del color normal.\n");

Lo normal es que estas cadenas se guarden en algún tipo de constantes, para luego usarlas y no tener que escribir la cadena de escape cada vez que queramos cambiar el color.

(Sacado de zeros and ones)

Muchas veces he oído aquello de que los programadores tenemos el ego muy alto, pero que la verdad es que los programas fallan más que una escopeta de feria, que si el hardware fallara tanto …

Cualquier atisbo de razón en este planteamiento muchas veces queda eclipsada por motivos ajenos a nuestro margen de maniobra. Y aquí va una experiencia como cualquier otra. Un buen día, ese proyecto de diseño de muslos de pollo que se abrió con una documentación de mierda y parecía que nunca iba a terminar por la continua adición de requisitos, al fin se termina. Se escoge un cliente incauto que quiera probarlo, para detectar bugs clamorosos, errores de concepto o carencias que al programador, que no se dedica a diseñar muslos de pollo, no se le puedan haber ocurrido.

La siguiente semana es un infierno, con el cliente todo el día al otro lado del teléfono. Todo falla. ¿Pero es así? No, en realidad su problema es que él quiere que el muslo de pollo se vea en color berenjena en lugar del color pollo. Te pasas toda la semana metiendo todas las chorradas (o no tan chorradas) que te van contando… y la cosa se olvida…

A los 3 meses, el cliente vuelve a la carga. Se ha estado rascando la nariz y repentinamente ha recordado tu programa. Y no le gusta. ¿Quién coño ha visto una vez un muslo de pollo color berenjena? Pero con un poco de suerte, al menos ahora te lo valida como que funciona y se empieza a plantear una difusión a todos los clientes que contrataron tu diseñador de muslos de pollo.

A los 6 meses de terminar la difusión a todos los clientes, haciendo el pino con las orejas con las mil y una versiones de sistemas operativos existentes (odio HP-UX), un día te suena el teléfono: “A fulanito no le funciona el diseñador de muslos de pollo, dice que le salen de pavo”. Joder, ¿y ahora esto cómo funcionaba? Ah, coño, que no funciona, que entre las mil chorradas que propuso el piloto estaba el poner los muslos de pavo, no de pollo. Así que no le funciona a nadie. Y han tardado 6 meses en darse cuenta.

Nadie probó el programa, nadie verificó el programa, nadie utiliza el programa; pero la culpa es tuya. Por hacerlo. Ahora exijo que los clientes piloto se encarguen de probar los programas en lugar de comprobar lo bonitos que son.

Aunque comencé explicándoos como funcionan las ventanas y los contenedores de GTK+ creo que lo mejor habría sido explicar primero qué son y cómo funcionan los widgets de GTK+. Así que aquí viene una explicación sobre los widgets.

La clase GtkWidget

Es la clase básica de la que parte cualquier otro widget de GTK+, esta clase en sí misma no hace nada específico (por ejemplo: un cuadro de texto, un botón, …) para ello existen clases específicas, como las ventanas o los contenedores. Estas clases más específicas heredan de la clase GtkWidget las funciones, atributos y señales básicas que les hacen ser clases válidas para poder usarse en GTK+.

Partes esenciales de un widget

Como cualquier clase de cualquier lenguaje de programación orientado a objetos, la clase de un widget se divide en:

• Funciones: Son las funciones que permiten trabajar con dicha clase. Aquí las llamo funciones porque estamos trabajando sobre C, si fuera sobre cualquier lenguaje de programación orientado a objetos las llamaría métodos.
• Atributos (o propiedades): Son variables asociadas a la clase que identifican propiedades de ésta, por ejemplo: el color, la altura, …
• Señales: Muchos lenguajes de programación orientada a objetos no usan señales, pero en GTK+ son necesarias para controlar los eventos.
  Las señales identifican el evento que se ha producido, y se deben asociar a alguna función para que GTK+ al interceptar la señal ejecute dicha función, por ejemplo: al pulsar un botón que se escriba un mensaje en un cuadro de texto, la señal sería la pulsación del botón y la función asociada a ella la escritura del mensaje en el cuadro de texto.

De este modo, en la documentación de la API de GTK+, se puede observar que cada widget se descompone en estas partes para que sepamos claramente qué se puede hacer y/o qué tareas realiza dicho widget.