Mostrando entradas con la etiqueta PyGTK. Mostrar todas las entradas
Mostrando entradas con la etiqueta PyGTK. Mostrar todas las entradas

Disponible versión 0.9.2 de Turpial

martes, enero 19, 2010




Por mucho que le dí vueltas a la cabeza para empezar este post, no puedo abrirlo de otra forma que no sea diciendo...

¡GRACIAS!


Gracias a todas las personas que han apoyado este proyecto de una u otra manera, gracias a los que se han tomado la molestia de probarlo, gracias por todos los RT y las menciones en Twitter, gracias por los buenos comentarios y las sugerencias, de verdad... ¡Muchas Gracias!. Gracias a la comunidad de Software Libre en general por la gran aceptación que le han dado a esta humilde aplicación... el Turpial.

Ahora sí... empecemos.

Siguiendo con un ciclo intensivo de desarrollo presento con orgullo la versión 0.9.2 de Turpial, el cliente Twitter con sabor Venezolano.

A pesar de que solo han pasado 4 días desde el lanzamiento de la versión anterior 0.8.5, hay un montón de cosas nuevas y bugs corregidos en esta nueva entrega.

Las novedades más resaltantes:

  • Añadida opción para configurar el número de tweets por columna
  • Resaltado de los tweets favoritos
  • Mejorados mensajes de error
  • Almacenado el tamaño que el usuario le asigne a la ventana
  • Corregido shebang del lanzador para hacerlo compatible con Fedora (gracias a Richzendy)
  • Agregado soporte para los servicios su.pr y bit.ly (cortado de URLs)
  • Usado el esquema de colores del perfil del usuario para los elementos resaltables
  • Soporte para abrir los hashtags desde el menú contextual
  • Añadido botón para limpiar las búsquedas
  • Mejoradas la detección de hashtags y menciones
  • Agregada la opción para activar/desactivar el sonido de las notificaciones
  • Mejorados los módulos de configuración y notificaciones
  • Corregidos otro bugs menores

Si ya tienes instalada una versión 0.8.x y quieres actualizar solo basta con que descargues la 0.9.2 y descomprimas la carpeta turpial, reemplazando la carpeta anterior. Todo debería funcionar sin ningún problema e incluso deberías conservar toda tu configuración intacta.

Debo decir que detrás de una aplicación como Turpial hay muchas horas de programación, pero también hay muchas horas de pruebas y detección de errores. Afortunadamente Turpial cuenta con un par de beta testers estrellas: Azrael Arocha y José Leonel Subero (aka arawako). Excelente trabajo muchachos.

Pueden seguir el progreso de Turpial en Twitter a través de @TurpialVe; también tenemos la página principal del proyecto en google code, una página de Preguntas y Respuestas Frecuentes (FAQs) y dos excelentes tutoriales; un Manual de Instalación en Ubuntu realizado por mi pana Renata Franco y un Manual de Uso hecho por el pana Turpial Beta Tester, Azrael. Ya no tienes excusas... ¡A probarlo!

De más está invitarlos a que lo descarguen, lo prueben, lo comenten y lo apoyen. No es necesario saber programar para apoyar y colaborar con el Turpial.

Espero que lo disfruten. Screenshots después del salto (click en las imágenes para agrandar)


Turpial 0.9.2


Nuevas funciones en el menú contextual y resaltado de favoritos


Soporte para nuevos servicios de cortado de URLs


Implementadas nuevas preferencias

¿Y tu, ya probaste Turpial? Cuéntanos que te pareció, deja tu comentario


Publicado Turpial 0.8: Más criollo que una arepa

lunes, enero 11, 2010




Hace aproximadamente un par de meses hice oficialmente la primera publicación de Turpial (v0.6); un cliente alternativo de Twitter para GNU/Linux escrito en Python.

Para aquel entonces solo contaba con interfaz para geeks modo texto y un buen repertorio de funciones. Ahora, gracias a la colaboración del pana Azrael, traemos la versión 0.8 con un montón de bugs corregidos y funciones nuevas, pero lo más importante... ¡con interfaz para gente normal! :D

Ha sido un trabajo duro, aún quedan MUCHAS cosas por terminar y otras más por corregir (si no me creen miren la lista de bugs y cosas pendientes xDDD), pero lo importante es que el trabajo está dando sus frutos y al menos alguien más, a parte de mi, usa Turpial (sí, es Azrael, y que!?)

Entre las características del nuevo Turpial tenemos:

  • Interfaz GTK+ para el modo gráfico (el modo texto está en reconstrucción)
  • Puedes ver el timeline, las menciones, los mensajes directos, los favoritos y el perfil del usuario
  • Permite tuitear, borrar tuits y retuitear
  • Marcar y desmarcar tuits favoritos
  • Soporta búsquedas
  • Envía mensajes directos (solo usando el comando D)
  • Dispone de servicios para cortado de URLs
  • Descarga las imágenes de los usuarios
  • Tiene una interfaz con respuesta mejorada (usando threads)
  • Notificaciones integradas con el entorno de escritorio (y con sonido)
  • Guarda las preferencias del usuario
  • Modo "wide" a 3 columnas
  • Nueva API usando la autenticación segura de Twitter (OAuth)

Para los interesados, aquí pueden descargarlo y tenemos una sección de FAQs (Preguntas y Respuestas Frecuentes) donde se aclaran dudas comúnes y se explica cómo instalarlo y probarlo (no, lamentablemente no explicamos cómo desinstalarlo)

Este nuevo Turpial viene con puro sabor venezolano y es casi tan criollo como comerse una buena arepa con queso y mantequilla, así que los invito a que lo prueben, lo comenten, lo compartan y si les gusta, lo apoyen.

Los dejo con una pequeña galería de screenshots pa' que se animen.







Es todo por ahora, cambio y fuera.





Tooltip en PyGTK para un IconView (insertado en un ScrolledWindow)

jueves, diciembre 03, 2009

Luego de pasar toda una tarde reventándome la cabeza y tomando psicotrópicos leyendo la documentación oficial de PyGTK y haciendo pruebas, logré conseguir mi objetivo: Mostrar un miserable tooltip sensible en un IconView usando la nueva API para Tooltips de PyGTK >= 2.12.

La forma antigua y tradicional de hacer un Tooltip era más rudimentaria; incluso habían formas que involucraban conectarse al evento 'motion-notify-event' del widget, obtener la celda en cuestión en base a la posición del ratón y crear la ventana a pie para luego mostrarla. Sin mencionar que era necesario manejar el tiempo de aparición del tooltip usando un timer y la desaparición del tooltip actual antes de mostrar uno nuevo. Nada trivial en realidad, pero así lo implementé en varias ocasiones.

La nueva API reduce todo el proceso a 3 simples pasos:
  • Establecer la propiedad has-tooltip del widget a True para que GTK pueda monitorear los eventos de movimiento relacionados con el tooltip
  • Conectarse a la señal 'query-tooltip' del widget. Esta señal será emitida cuando el tooltip deba ser mostrado. Uno de los argumentos pasados a la señal es un objeto Tooltip correspondiente al widget. Solo queda de nuestra parte modificarlo
  • Retornar True desde el callback que maneja la señal 'query-tooltip' para mostrar el tooltip o False para que no se muestre

Sencillo, ¿eh?. La API es realmente buena y facilita un montón la creación de un Tooltip, de hecho es tan sencillo que parace increible xD. Pero... se les pasó un pequeño detalle... las ventanas de desplazamiento (ScrolledWindow).

Cuando se usa un widget que es o será más grande que el espacio disponible para dibujarlo (TreeView, TextView, IconView, etc) se debe emplear un ventana con scroll (ScrolledWindow) e insertar el widget dentro de ella. La ScrolledWindow se encargará de manejar eso de los scrollbars, el viewport, etc, etc, etc (si no entiendes de que estoy hablando te recomiendo leer este apartado del tutorial de PyGTK). Muy bonito todo... hasta ahora.

El problema aparece cuando queremos mostrar un tooltip sensible para un IconView/TreeView (es decir, que el tooltip mostrará información diferente para cada elemento del contenedor) pues la famosa señal 'query-tooltip' dentro de sus argumentos pasa la posición RELATIVA del cursor mediante x e y:

def callback(widget, x, y, keyboard_mode, tooltip, user_param1, ...)

¿Qué significa la 'posición relativa del cursor'? Pues, en un widget sin scroll es la posición exácta del cursor sobre ese widget, pero en un widget con scroll ocurre lo siguiente:



La señal 'query-tooltip' nos devuelve lo que en la imagen se ve como X e Y, es decir la posición del elemento relativa al ScrolledWindow. Bien.

Ahora, para saber a cual elemento del IconView estamos haciendo referencia hace falta conocer las coordenadas del elemento (relativas al IconView) y ubicar en el modelo el registro correspondiente.

¿Cómo demonios vamos a obtener el elemento del IconView si la señal nos devuelve unas coordenadas que no nos sirven? ¿Cómo rayos obtenemos los valores de Z y W para referenciar al objeto correctamente?

Pues he aquí la solución, y es más fácil de lo que parece. El código se explica con los comentarios.

# -*- coding: utf-8 -*-

import gtk

class PruebaTooltip:
    def __init__(self):
        # Creamos nuestro modelo con 2 campos, uno para la imagen y otro para 
        # la descripción
        self.model = gtk.ListStore(gtk.gdk.Pixbuf, str)
        
        # Creamos el IconView
        self.iconview = gtk.IconView(self.model)
        # Le decimos que la imagen la sacará de la primera columna
        self.iconview.set_pixbuf_column(0)
        # Habilitamos el nuevo soporte de la API para tooltips
        self.iconview.set_has_tooltip(True)
        self.iconview.set_orientation(gtk.ORIENTATION_VERTICAL)
        self.iconview.set_selection_mode(gtk.SELECTION_SINGLE)
        self.iconview.set_column_spacing(10)
        self.iconview.set_columns(6)
        self.iconview.set_item_width(50)
        # Nos conectamos a la señal 'query-tooltip'
        self.iconview.connect("query-tooltip", self.show_tooltip)
        
        # Creamos el ScrolledWindow y le insertamos el IconView
        self.scrollwin = gtk.ScrolledWindow()
        self.scrollwin.set_policy(gtk.POLICY_AUTOMATIC, gtk.POLICY_AUTOMATIC)
        self.scrollwin.set_shadow_type(gtk.SHADOW_IN)
        self.scrollwin.add(self.iconview)
        
        vbox = gtk.VBox(False, 5)
        vbox.pack_start(self.scrollwin, True, True, 0)
        
        # Creamos una ventana simple y le agregamos la caja que contiene la
        # ScrolledWindow y todo lo demás
        self.window = gtk.Window()
        self.window.set_title('Tooltip de in IconView como debe ser')
        self.window.set_default_size(300, 300)
        self.window.set_position(gtk.WIN_POS_CENTER)
        self.window.connect('destroy', gtk.main_quit)
        self.window.add(vbox)
        self.window.show_all()
        
        # Creamos unos cuantos elementos dentro del modelo (esto es solo con 
        # fines ilustrativos, pues en teoría debería llenarse desde otra parte)
        for i in range(30):
            label = 'Tooltip del Elemento %i' % (i + 1)
            pix = self.window.render_icon(gtk.STOCK_ABOUT, gtk.ICON_SIZE_DIALOG)
            self.model.append([pix, label])
        del pix
    
    # Esta es la parte ruda xD
    # Nuestro callback para la señal 'query-tooltip'
    def show_tooltip(self, widget, x, y, keyboard_mode, tooltip):
        # Calculamos el offset (w y x), es decir la diferencia entre el origen 
        # del ScrolledWindow y el IconView. Para eso usamos el valor de cada uno
        # de los scrollbar. Simple ¿no?. Pues después de los psicotrópicos lo
        # ví muy sencillo :P
        w = self.scrollwin.get_property('hadjustment').value
        z = self.scrollwin.get_property('vadjustment').value
        
        # Ubicamos la ruta del elemento según la posición 'exácta' del cursor
        # sobre el IconView
        path = widget.get_path_at_pos(int(x + w), int(y + z))
        if path is None: return False
        
        model = widget.get_model()
        
        # Obtenemos el elemento mediante el modelo y la ruta
        iter = model.get_iter(path)
        
        # Obtenemos la imagen y la descripción guardada en el modelo
        pix = model.get_value(iter, 0)
        desc = model.get_value(iter, 1)
        # Establecemos la imagen del tooltip
        tooltip.set_icon(pix)
        # Establecemos el texto del tooltip (con soporte para marcado pango :D)
        tooltip.set_markup(desc)
        # Borramos la imagen para no dejar basura regada
        del pix
        
        # Devolvemos True para que se muestre el Tooltip y seamos felices weee!
        return True
        
if __name__ == "__main__":
    PruebaTooltip()
    gtk.main()

Al final veremos algo así:



Pues sí, eso es todo... una simple suma. Lo que me reventó el coco fue saber de donde diablos sacar los valores de W y Z (los offset). Espero que hayan podido leer este post antes de pensar en implementar los Tooltips a la Old-Fashion Way e incluso antes de pensar en el suicidio xD.

Cambio y fuera

Turpial: Un cliente Twitter para GNU/Linux con todos los hierros

miércoles, noviembre 18, 2009


Turpial es un cliente Twitter multi-interfaz escrito en Python que he estado desarrollando con el pana Eleazar Meza, orientado a ser una alternativa a los clientes Twitter más populares para GNU/Linux (aunque por su naturaleza también puede correr bajo otras plataformas).

La idea surgió hace poco más de 2 semanas y no son solo ganas de reinventar la rueda (considerando que DestroyTwitter, TweetDeck et al. están disponibles para Linux), sino que se quiere lograr un cliente que también corra en entornos de escritorio ligeros como Fluxbox, OpenBox, etc (pensando en las netbooks), ya que Adobe Air solo corre en KDE/GNOME y la mayoría de los cliente basados en GTK son soluciones asquerosamente simples que carecen de una gran cantidad de funciones.

Su nombre proviene del ave nacional de Venezuela (el turpial) y está inspirado principalmente por la sencillez y la funcionalidad de DestroyTwitter pero con el objetivo de tener varias interfaces: una interfaz en línea de comandos, una GTK pura y una más innovadora y bleeding-edge usando diferentes recursos y tecnologías como Cairo y Webkit, entre otras.

Actualmente Turpial se encuentra en estado de desarrollo intenso, por lo que pueden presentarse errores y fallos inesperados. Sin embargo, se invita a los valientes y verdaderos geeks la comunidad en general a que prueben Turpial y si detectan algún fallo lo reporten a cualquiera de las siguientes direcciones:

wil.alejandro at gmail.com < Wil Alvarez >
meza.eleazar at gmail.com < Eleazar Meza >

Características

Turpial ya cuenta con soporte para las siguientes funciones:
  • Ver tweets del timeline, menciones y favoritos
  • Ver y enviar mensajes directos
  • Actualizar estado (tuitear)
  • Ver following y followers
  • Buscar personas
  • Hacer follow o unfollow a cualquier usuario
  • Mostrar trending topics
  • Hacer mute/unmute a cualquier usuario

Quedan pendientes para las próximas actualizaciones:
  • Ver tweets sobre un tópico o un hashtag seleccionado
  • Cortar URLs y subir imágenes (con soporte para agregar diferentes servicios)
  • Agrupar tweets como conversaciones
  • Mostrar listas a las que el usuario pertenece y los tweets correspondientes a cada lista
  • Guardar las preferencias del usuario

Requisitos


Turpial necesita los siguientes paquetes para funcionar correctamente:

* python >= 2.5
* python-simplejson >= 2.0.x

Una instalación estándar de Python (como la que viene en la mayoría de las distribuciones GNU/Linux) es más que suficiente. El módulo de python para simplejson se puede instalar en las distribuciones basadas en Debian con el siguiente comando (como superusuario):

# aptitude install python-simplejson

¿Cómo diablos ejecuto Turpial?


Muy fácil. Para ejecutar Turpial en un ambiente GNU/Linux basta con descargar el siguiente archivo, descomprimirlo y en la carpeta turpial ubicar el archivo turpial.py, otorgarle permisos de ejecución y ejecutarlo (como usuario regular):

$ chmod +x turpial.py
$ ./turpial.py


Al momento de esta publicación la única interfaz disponible para Turpial es la elitista, l33t, unix-like y hardcore de línea de comandos. Basta con escribir "help" en la consola para obtener una lista de comandos disponibles o "help <comando>" para una ayuda detallada para el comando seleccionado.

Comentarios, sugerencias, reportes de bugs y cualquier otra información que pueda alimentar nuestro ego será bienvenida.

Cairo, PyWebKit y PyGTK: Semana de Pruebas

jueves, octubre 22, 2009

Esta ha sido una semana de pruebas, pruebas y más pruebas. Estoy trabajando en eso de mejorar las interfaces en PyGTK y pretendo apoyarme en Cairo y WebKit. He investigado un poco de ambos; los resultados han sido alentadores.

Primera prueba de la semana: Cairo

Cairo es una librería que permite dibujar sobre un widget (canvas o lienzo). Y cuando digo dibujar, me refiero a dibujar. Trazar líneas, rectángulos, arcos y cosas por el estilo.

Lo primero que se me ocurrió hacer para probar Cairo fue un medidor. Para esto solo me haría falta un slider vertical y el canvas para dibujar. La idea es que el medidor se llene o se vacíe según el deslizamiento de la barra.

El código del medidor quedó así (se explica con los comentarios):
#!/usr/bin/python

# Ejemplo de widget con Cairo
#
# Author: Wil Alvarez (aka Satanas)
# Oct 19, 2009

import gtk
import cairo

# Creamos una clase que herede de gtk.DrawingArea para usarla como canvas
class Cpu(gtk.DrawingArea):
    def __init__(self, parent):
        self.par = parent
        gtk.DrawingArea.__init__(self)
        # Nos conectamos al evento expose, pues allí es donde ocurre toda 
        # la diversión
        self.connect('expose-event', self.expose)
        self.set_size_request(130, 200)
    
    # Este evento se ejecuta cada vez que la aplicación necesita redibujarse
    # o cuando cambiamos un valor y mandamos a redibujarla. Aquí se pintará
    # y se le dará forma al widget
    def expose(self, widget, event):
        # Aquí obtenemos el contexto de cairo
        cr = widget.window.cairo_create()
        cr.set_line_width(0.8)
        
        # Definimos un rectángulo para limitar el proceso de dibujado y así
        # optimizar la operación
        cr.rectangle(event.area.x, event.area.y, 
            event.area.width, event.area.height)
        cr.clip()
        
        cr.rectangle(0,0,130,200)
        cr.set_source_rgb(0, 0, 0)  # Establecemos el color de la brocha/pincel
        cr.fill()
        
        # Obtenemos el valor actual del slider
        x = (self.par.cur_value * 34) / 100
        
        # Dibujamos 34 barritas para el medidor y según el valor de 'x'
        # decidimos si está 'encendida' o no
        for i in range(34):
            if (i < 34 - x):
                cr.set_source_rgb(0.53, 0, 0)
            else:
                cr.set_source_rgb(1, 0, 0)
            
            h = 15 + (i*5)
            cr.rectangle(15,h,49,4)
            cr.fill()
            
            cr.rectangle(67,h,49,4)
            cr.fill()

# Creamos una ventana sencilla en PyGTK con el slider y el canvas
class PyApp(gtk.Window):
    def __init__(self):
        gtk.Window.__init__(self)
        
        self.set_title('CPU Meter')
        self.set_size_request(200, 200)
        self.set_position(gtk.WIN_POS_CENTER)
        self.connect('destroy', gtk.main_quit)

        self.cur_value = 10
       
        vbox = gtk.VBox(False, 2)
        
        scale = gtk.VScale()
        scale.set_range(0, 100)
        scale.set_digits(0)
        scale.set_size_request(35, 160)
        scale.set_value(self.cur_value)
        scale.set_inverted(True)
        scale.connect('value-changed', self.on_changed)
        
        self.cpu = Cpu(self)
        
        hbox = gtk.HBox(False)
        hbox.pack_start(self.cpu)
        hbox.pack_start(scale)
        
        vbox.pack_start(hbox, True, True, 2)

        self.add(vbox)
        self.show_all()
        
    # Programamos el evento 'value-changed' de la barra para que con cada
    # cambio mande a redibujar al widget del medidor
    def on_changed(self, widget):
        self.cur_value = widget.get_value()
        self.cpu.queue_draw()


    def get_cur_value(self):
        return self.cur_value

PyApp()
gtk.main()
Al final la aplicación quedó así:



Bastante aceptable para mi gusto. El código pueden descargarlo aquí


Segunda prueba de la semana: PyWebKit

La segunda prueba fue con PyWebKit. Esta prueba me ha frustrado un poco por la dificultad de conseguir documentación o referencias sobre la API de PyWebKit. Fue una labor árdua. Tuve que descargar varios códigos fuentes; entre ellos el de Gwibber (cliente de Twitter) y hasta el del mismísimo PyWebKit para lograr acercame a algo vagamente funcional.

El único ejemplo que traía PyWebKit era el de un navegador que soporta pestañas y otro centenar de características, por lo que no era para nada sencillo comprender su código (¿a quién se le ocurriría poner ese ejemplo? BIG FAIL! Es solo un demo, ¡rayos!... No el próximo Firefox, Opera o Safari).

El código de gwibber era de lejos más comprensible, aunque no menos complejo (se lo justifico por ser una aplicación de verdad no un ejemplo). Después de mucho leer, digerir implementaciones de controles GTK, fumarme unas cuantas lumpias y otros esoterismos, pude dar con el método que permite insertar código HTML directamente sobre el widget... el famoso load_string.

La cuestión con PyWebKit es relativamente simple, porque después que dominamos el load_string lo demás es carpintería HTML y CSS.

El código de la prueba a continuación:

#!/usr/bin/python

# Ejemplo de widget con WebKit
#
# Author: Wil Alvarez (aka Satanas)
# Oct 20, 2009

import gtk
import webkit
import gobject
gobject.threads_init()

# Codigo HTML que insertaremos al control para que lo muestre
ABOUT_PAGE = """
<html><head><title>PyWebKitGtk</title></head><body>
<h1>Mi primera prueba con PyWebKit</h1>
<p><a href="http://code.google.com/p/pywebkitgtk/">http://code.google.com/p/pywebkitgtk/</a><br/>
</p>
<div style="border: 1px solid #000; width:300px; height: 100px; background-color:#aaa;">
  zOMG! This is fucking awesome<br/><br/>
  No se que más poner en este div con estilos css  XDDD
</div>
</body></html>
"""

# Clase donde sobreecribimos el widget WebView de WebKit para implementar
# nuestro código y hacer uso del load_string para inyectar HTML directamente
# sobre el control (sin usar URI o algo similar)
class MessageStreamView(webkit.WebView):
    def __init__(self):
        webkit.WebView.__init__(self)
        self.connect("navigation-requested", self.on_click_link)
        
        self.settings = webkit.WebSettings()
        self.set_settings(self.settings)
        
        # Recibe como parámetros el código HTML, el mime-type de la página,
        # la codificación y un URI
        self.load_string(ABOUT_PAGE, "text/html", "iso-8859-15", "about")
        
    def on_click_link(self, view, frame, req):
        uri = req.get_uri()
        print uri
        return True

# Creamos una ventana simple en PyGTK con el control que acabamos de crear y 
# voilá! Tenemos nuestro widget que renderiza páginas web con el motor WebKit
class Simulador(gtk.Window):
    def __init__(self):
        gtk.Window.__init__(self)
        self.set_title('Pruebas de Gwibber, Webkit y otras shits')
        self.set_default_size(400, 400)
        self.set_position(gtk.WIN_POS_CENTER)
        self.connect('destroy', gtk.main_quit)
        
        messages = MessageStreamView()
        
        vbox = gtk.VBox(False, 5)
        vbox.pack_start(messages, True, True, 0)
        
        self.add(vbox)
        self.show_all()
    
Simulador()
gtk.main()
La ventana luce así:



Y el código pueden descargarlo aquí.

Aún no estoy muy satisfecho con la información que tengo de PyWebKit, lo mejor que he conseguido es una lista con los nombres de los métodos de la API y más nada, así que seguiré buscando.


Conslusiones

Cada librería tiene un ámbito diferente, por lo que la idea no es establecer una comparación uno a uno entre ellas, sino destacar los pro y los contra para forjar una idea de hasta donde podemos llegar con ellas.

PyWebKit

La mayor desventaja de PyWebKit es la falta de documentación. No me importaría tener una documentación vulgar, chapucera y hasta con errores ortográficos, con tal de al menos tener una! Sin embargo, para compensar eso podemos decir que PyWebKit nos otorga todo el poder y la flexibilidad de un motor de renderizado como WebKit. El límite lo pone nuestro manejo de HTML/CSS y el nivel de implementación de PyWebKit.

Cairo

Cairo tampoco tiene documentación ofical (o no la he encontrado aún) pero al menos hay unos cuantos tutoriales en la red que te dan luces acerca de su funcionamiento y sus métodos básicos. La principal ventaja de Cairo es que nos da la oportunidad de ser artistas sobre un widget xD, incluso creo que se puede usar OpenGL para acelerar el renderizado y aplicar efectos 3D... así que el límite lo pone nuestra imaginación. Pero como diría el abuelo de Peter Parker:

Un gran poder trae consigo una gran responsabilidad

Y esto es porque Cairo se utiliza en controles GTK que hacen las veces de lienzo; podemos imaginarlo como un control más de GTK pero que podemos dibujar a nuestro antojo. Esto trae una consecuencia, pensar en una aplicación desarrollada completamente con Cairo requiere una inversión de trabajo enorme (y quizás injustificada e innecesaria) pues Cairo como tal no tiene widgets, así que nos tocaría implementar desde cero cada control que queramos utilizar; entiéndase cajas de texto, etiquetas, botones y ni hablar de las listas y elementos con scroll... sería una verdadera pesadilla.

Ambas librerías tienen un enorme potencial, cada una en su ámbito y creo que la fórmula ganadora está en una buena combinación de ambas. Ni más ni menos.

Para la próxima entrega postearé las segundas pruebas con Cairo y las pruebas con DBus y el sistema de notificaciones de Ubuntu, NotifyOSD.

Referencias
[1] http://www.zetcode.com/tutorials/pygtktutorial/customwidget/
[2] http://zetcode.com/tutorials/cairographicstutorial/customgtkwidget/
[3] http://www.pygtk.org/articles/cairo-pygtk-widgets/cairo-pygtk-widgets.htm
[4] http://www.tortall.net/mu/wiki/CairoTutorial
[5] http://jackvalmadre.wordpress.com/2008/09/21/resizable-image-control/
[6] http://www.pygtk.org/articles/cairo-pygtk-widget-signals-es/cairo-pygtk-widget-signals.html
[7] http://trac.webkit.org/attachment/wiki/HackingGtk/webkit.api

Shoes, Cairo y PyGTK

jueves, febrero 26, 2009

Estuve conversando ayer con un amigo sobre toolkits sencillos y rápidos para desarrollar aplicaciones gráficas multiplataforma. Hablamos de FLTK, de ETK, de murgaLua, obviamente del GTK+ y Qt4 y hasta del mismísimo infame Gambas. Es ahí cuando el pana me presenta a "Shoes" <fanfarria con bombos platillos>.

Shoes (a.k.a alfombra, media, chancleta o como te provoque llamarlo =P) es un toolkit muy pequeño y que por sí solo puede hacer cosas realmente impresionantes. Según su creador "... puedes hacer aplicaciones realmente colorídas..." y se lo creo. Para muestra un botón



Está hecho en Ruby pero su sintaxis es tan simple que parece HTML con CSS (claro gracias en parte a los bloques de código Ruby). La cuestión me llamó tanto la atención que decidí probarlo y mi conclusión: es sencillamente maravilloso. El código es tan limpio, tan simple y tan intuitivo que dan ganas de poner a volar la imaginación para desarrollar cuanta cosa se te ocurra.

Y es que el simple hecho de que pueda hacer una ventana con un fondo degradado con tan solo 7 miserables líneas de código me hace sangrar la nariz.
Shoes.app do
background "#F3F".."#F90"
title "Shoooes", :top => 60,
:align => "center",
:font => "Trebuchet MS",
:stroke => white
end

Sin embargo me surgió una pregunta: ¿Por qué Ruby? y e instantáneamente surgió otra: ¿No habrá un Shoes para Python? La respuesta a la segunda es NO. La respuesta a la primera aún la desconozco.

Si aún están leyendo se preguntarán: ¿Y que tiene que ver todo esto con Cairo y PyGTK? Pues muy simple, revisando el código fuente de Shoes me di cuenta que una ventana no es más que un lienzo (o canvas) y que ese lienzo _aparentemente_ lo crean y lo trabajan con Cairo. Suena muy simple, pero créanme... no lo es.

Fue ahí donde se me ocurrió la idea: ¿Por qué no hacer una implementación de Shoes para Python usando Cairo? y pues bueno aquí estoy, leyendo todo cuanto encuentro sobre Cairo y PyGTK. He leído un par de blogs donde dicen como trabajar con Cairo y PyGTK, además de la documentación de Cairo. Entre ellos:

http://blog.rastersoft.com/index.php/2007/06/20/trabajando-con-pycairo-y-gtk/

http://blog.eikke.com/index.php/ikke/2007/02/17/python_cairo_xshape_and_clocks

http://cairographics.org/documentation/pycairo/reference/index.html#reference-index

Apenas he corrido un par ejemplos y todo parece funcionar muy bien. Seguiré investigando y publicando mis progresos.

Cambio y fuera