PDF de programación - Desarrollo de aplicaciones con Kiwi2 y Gazpacho

Desarrollo de aplicaciones con 

Kiwi2 y Gazpacho

Lorenzo Gil Sánchez

[email protected]

SICEm. Software Integrado para el Control de la Empresa.

Jorge Guillén, 19, Ático, 18220 Albolote (Granada)

Resumen: Kiwi2 es un marco de trabajo que facilita el desarrollo rápido de
aplicaciones gráficas y que utiliza el toolkit GTK+. Ofrece conceptos de alto
nivel de abstracción basados en la arquitectura MVC (Modelo-Vista-
Controlador) con algunas mejoras. También contiene un conjunto de
controles gráficos potentes y cómodos para el desarrollador y el usuario.
Gazpacho es un diseñador de interfaces de usuario que hace hincapié en la
usabilidad y soporte de las últimas tecnologías de GTK+. Ambas
herramientas están escritas en el lenguaje de programación Python. En este
artículo se describen los principales conceptos de Kiwi2 y también las
ventajas de Gazpacho respecto a otros sistemas de diseño de interfaces. Se
facilitan ejemplos sencillos para mejorar la comprensión final.

1. El marco de trabajo Kiwi2

1.1 Introducció n

Controlador

Vista

Proxy

Delegador

Modelo

Kiwi2 es un paquete para Python que facilita enormemente el desarrollo de
aplicaciones gráficas en este lenguaje. Kiwi2 funciona sobre GTK+ 2.4 o posterior y
es la evolución de Kiwi1 (o simplemente Kiwi) que funciona sobre GTK+ 1.2. Kiwi2

no es simplemente la adaptación de Kiwi1 para GTK+ 2 sino que en su desarrollo se
han rediseñado sus componentes internos manteniendo casi por completo la interfaz
externa o API.
Kiwi es software libre (LGPL) desarrollado por la compañía brasileña Async1. Esta
segunda versión de Kiwi se ha desarrollado en colaboración con la empresa española
Sicem2.
Kiwi es una librería que ha surgido como un proceso natural de abstracción de un
código que venía siendo utilizado una y otra vez en aplicaciones empresariales
desarrolladas por Async. Con el objetivo principal de la reutilización de código se
hizo un estudio de las similitudes y relaciones del código que se repetía en dichas
aplicaciones a nivel de interfaz de usuario. De esta manera se formalizaron los
conceptos e ideas que dan forma a Kiwi: Vistas, Controladores, Delegadores, Proxys
y Modelos.
Un proyecto similar es Bakery, de Murray Cumming, que pretende alcanzar objetivos
similares de reutilización de componentes de interfaces gráficas para programas
escritos en C++.
A continuación se explican estos conceptos, básicos para entender el funcionamiento
de una aplicación que utilice Kiwi.

1.2 Vistas (Views)
Una Vista es una parte de la interfaz de la aplicación que ve y manipula el usuario
final. En Kiwi2 hay dos tipos de vistas, vistas normales (BaseView) y vistas esclavas
(SlaveView). Una vista normal contiene una ventana y, habitualmente, controles
dentro de ella. Una vista esclava es un conjunto de controles agrupados según un
criterio común, normalmente debido a que son controles que manipulan atributos del
mismo objeto en nuestra aplicación.

Los dos tipos de vistas pueden contener a su vez subvistas esclavas. De esta forma se
introduce el concepto de reutilización de partes de la interfaz de usuario. Por ejemplo,
en una aplicación de gestión habitualmente es necesario visualizar los datos asociados
a un cliente. Se puede diseñar un formulario con dichos datos y utilizar una vista
esclava a partir de él. Una vez hecho esto, esta vista se puede utilizar sin problemas
desde cualquier parte de la aplicación, incrustada en otras vistas más específicas.

Las vistas de Kiwi pueden crear sus controles manualmente (escribiendo la definición
de los controles en el código del programa) o a partir de un fichero Glade que puede
ser generado por Glade-2 o bien por Gazpacho. Más adelante se explicarán las
ventajas de diseñar las interfaces con Gazpacho.
A continuación se muestra un ejemplo del uso de vistas y archivos glade:
01 from Kiwi2 import Views
02 from Kiwi2.initgtk import gtk, quit_if_last
03
04 app = Views.BaseView(gladefile="hey", delete_handler=quit_if_last)
05 app.show()

1 http://www.async.com.br
2 http://www.sicem.biz

06 gtk.main()

En este ejemplo se esta cargando la interfaz de usuario de un archivo denominado
hey.glade y como se puede ver sólo consiste en una ventana con una etiqueta de texto.

1.3 Controladores (Controllers)
Para que una vista sea útil es necesario asociar comportamiento a los distintos eventos
que el usuario genera mediante su interacción con la interfaz. Por ejemplo,
normalmente se guardan los datos que el usuario introduce en los formularios de la
aplicación o se realizan cálculos cuando se pincha en los botones. En la terminología
de aplicaciones gráficas esto se consigue asociando funciones a dichos eventos. Estas
funciones o retrollamadas de eventos (event callbacks) serán ejecutadas cuando se
produzcan los eventos correspondientes. En GTK+ a los eventos se les suele
denominar señales y aunque no son exactamente lo mismo, en este documento no es
necesario resaltar sus diferencias.

En Kiwi el programador escribe sus retrollamadas como métodos de una subclase de
la clase Controller. Esta clase, junto con la clase View permiten asociar eventos de los
controles con métodos de una forma muy sencilla. La asociación se realiza en base al
nombre del método siguiendo la siguiente sintaxis:

[on|after]_nombre_del_control__nombre_de_la_señal
Por ejemplo, si el método on_button1__clicked existe, cuando el usuario haga click
en el botón “button1” el método será ejecutado automáticamente. Esta forma de
asociar señales con código ejecutable tiene las siguientes ventajas:

● Uniformidad en el estilo de las retrollamadas

● Legibilidad de dichas retrollamadas. Solo viendo el nombre del método nos

hacemos una idea de cuándo será llamado

● Facilidad de programación. No es necesario hacer la conexión entre los controles,

las señales y las retrollamadas ya que Kiwi lo hace internamente.

A continuación se muestra un ejemplo del uso de un controlador:

01 from Kiwi2 import Views, Controllers
02 from Kiwi2.initgtk import gtk, quit_if_last
03
04 class FarenControl(Controllers.BaseController):
05    def __init__(self, view):
06        Controllers.BaseController.__init__(self, view)
07
08    def on_quitbutton__clicked(self, *args):
09        self.view.hide_and_quit()
10
11    def after_temperature__changed(self, entry, *args):

12        try:
13            temp = float(entry.get_text())
14        except ValueError:
15            temp = 0
16        celsius = (temp ­ 32) * 5/9.0
17        farenheit = (temp * 9/5.0) + 32
18        self.view.celsius.set_text("%.2f" % celsius)
19        self.view.farenheit.set_text("%.2f" % farenheit)
20
21 widgets = ["quitbutton", "temperature", "celsius", "farenheit"]
22 view = Views.BaseView(gladefile="faren", delete_handler=quit_if_last,
23                       widgets=widgets)
24 ctl = FarenControl(view)
25 view.show()
26 gtk.main()

En las lineas 21-22 se puede que se están nombrando explícitamente una serie de
controles y dicha lista se le pasa al constructor de la Vista. En el archivo glade se han
definido esos nombres para algunos controles de la interfaz y el objetivo es poder
acceder a dichos controles como si fueran miembros de nuestra clase vista.

En las lineas 8 y 10 se definen dos métodos con el formato de nombre que se ha
explicado anteriormente. Es fácil intuir cuándo serán llamados y el efecto que
producen.

1.4 Delegadores (Delegates)
Uno de los problemas de la arquitectura MVC es que la separación entre la Vista y el
Controlador dificulta la programación de ambas clases y, habitualmente, no supone
una ventaja en cuanto a la reutilización de componentes ya que las retrollamadas en el
Controlador suelen estar muy ligadas a la Vista particular con la que trabaja. En otras
palabras, normalmente es necesario que la Vista ofrezca una API para sus controles
que el Controlador utiliza y para casos no triviales supone un exceso de trabajo sin
ventajas prácticas.

Para resolver este problema en Kiwi existe la clase Delegate que no es más que una
clase que hereda tanto de View como de Controller. En una aplicación que utiliza
Kiwi, la mayoría de las clases son subclases de Delegate.

En la clase Delegate se colocan los controles (View) y el código asociado a ellos

(Controller) y si bien esto parece ser contraproducente en cuanto la separación que
aboga la arquitectura MVC, lo cierto es que, en la práctica, se consiguen componentes
más reutilizables con esta filosofía.

Veamos el ejemplo anterior de conversor de temperatura utilizando un delegador:

01 from Kiwi2 import Delegates
02 from Kiwi2.initgtk import gtk, quit_if_last
03
04 class Farenheit(Delegates.Delegate):
05     widgets = ["quitbutton", "temperature", "celsius", "farenheit",
06                                 "celsius_label"   ,   "farenheit_label",
"temperature_label"]
07     def __init__(self):
08         Delegates.Delegate.__init__(self, gladefile="faren",
09                                     delete_handler=quit_if_last)
10
11     def convert_temperature(self, temp):
12         farenheit = (temp * 9/5.0) + 32
13         celsius = (temp ­ 32) * 5/9.0
14         return farenheit, celsius
15 
16     def clear_temperature(self):
17         self.farenheit.set_text("")
18         self.celsius.set_text("")
19
20     # Signal handlers
21     def on_quitbutton__clicked(self, *args):
22         self.hide_and_quit()
23
24     def after_temperature__changed(self, entry, *args):
25         temp = entry.get_text().strip() or None
26         if temp is None:
27             self.clear_temperature()
28         else:
29                           farenheit,   celsius   =   self.convert_temperature(float
(temp))
30             self.farenheit.set_text("