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.

Una API de Twitter para Python simplemente hermosa

domingo, noviembre 08, 2009

Mi proyecto Turpial requiere una API de Twitter para Python y los que me conocen saben que siempre me inclino por las cosas simples y minimalistas. En la búsqueda de la API adecuada me conseguí con esta joya de Mike Verdone: Python Twitter Tools.

Esta API no es tan conocida como por ejemplo python-twitter de DeWitt Clinton, pero sin duda alguna es hermosa. En poco más de 125 líneas implementa toda la funcionalidad de Twitter y además incluye un set de herramientas para probar la API desde una consola; así como también un bot IRC.

Me impresiona la simplicidad de esta API y lo bien elaborada que está. Implementa todo con una clase de un solo método que maneja todo. Es una excelente librería que se ha ganado mi respeto y admiración y por es la he elegido como API para Turpial xD.

Cualquier otra cosa que diga, estará de más. Su belleza se puede apreciar viendo su código y probándola. Recomendada 200%

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

Blog Action Day 2009 - Cambio Climático

jueves, octubre 15, 2009

Hoy es un día especial. Es un día en el que los blogeros de todo el mundo nos unimos a una sola voz por un fin común. Hoy 15 de Octubre de 2009 nos unimos para enfrentar uno de los problemas más urgentes que ataca a nuestro planeta... El cambio climático. Es nuestra oportunidad de llegar a cientos de miles de personas y cambiar el curso de la historia. Escribe en tu blog sobre el cambio climático. Cualquier aporte es bueno. Eso es el Blog Action Day 2009 y yo estoy dentro. Tú... ¿Qué esperas?

Cierro con una premisa muy conocida en el mundo del Software Libre y un video:

No es lo mismo adaptarse a los cambios que provocarlos




Error con Ruby 1.8 y Rails 1.2.6 en Debian Squeeze

lunes, octubre 05, 2009

Estaba yo una tarde de lo más tranquilo, programando mi sistema de compras de café verde mientras tarareaba una canciónde Bloodbath xD. En una de esas me dispongo a correr las migraciones de mi proyecto para actualizar la base de datos y para mi sorpresa ¡la migración falla!. El error (nada explícito) a continuación:

$ rake db:migrate
(in /home/satanas/proyectos/cvacafe/sicca)
rake aborted!
{:root=>"(as the the label for a named route) will become a shortcut for map.connect '', so find another name"} is not a symbol

(See full trace by running task with --trace)


Al ver la verbosidad del mensaje invoco el comando pero con la opción --trace tal como me lo sugiere la advertencia y obtengo esto:

$ rake db:migrate --trace
(in /home/satanas/proyectos/cvacafe/sicca)
** Invoke db:migrate (first_time)
** Invoke environment (first_time)
** Execute environment
rake aborted!
{:root=>"(as the the label for a named route) will become a shortcut for map.connect '', so find another name"} is not a symbol
/usr/lib/ruby/1.8/deprecated.rb:176:in `instance_method'
/usr/lib/ruby/1.8/deprecated.rb:176:in `deprecate'
/usr/lib/ruby/gems/1.8/gems/actionpack-1.13.6/lib/action_controller/routing.rb:994
/usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require'
/usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:27:in `require'
/usr/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/dependencies.rb:495:in `require'
/usr/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/dependencies.rb:342:in `new_constants_in'
/usr/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/dependencies.rb:495:in `require'
/usr/lib/ruby/gems/1.8/gems/actionpack-1.13.6/lib/action_controller/base.rb:4
/usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require'
/usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:27:in `require'
/usr/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/dependencies.rb:495:in `require'
/usr/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/dependencies.rb:342:in `new_constants_in'
/usr/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/dependencies.rb:495:in `require'
/usr/lib/ruby/gems/1.8/gems/actionpack-1.13.6/lib/action_controller.rb:37
/usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require'
/usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:27:in `require'
/usr/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/dependencies.rb:495:in `require'
/usr/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/dependencies.rb:342:in `new_constants_in'
/usr/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/dependencies.rb:495:in `require'
/usr/lib/ruby/gems/1.8/gems/rails-1.2.6/lib/initializer.rb:166:in `require_frameworks'
/usr/lib/ruby/gems/1.8/gems/rails-1.2.6/lib/initializer.rb:166:in `each'
/usr/lib/ruby/gems/1.8/gems/rails-1.2.6/lib/initializer.rb:166:in `require_frameworks'
/usr/lib/ruby/gems/1.8/gems/rails-1.2.6/lib/initializer.rb:87:in `process'
/usr/lib/ruby/gems/1.8/gems/rails-1.2.6/lib/initializer.rb:47:in `send'
/usr/lib/ruby/gems/1.8/gems/rails-1.2.6/lib/initializer.rb:47:in `run'
/home/satanas/proyectos/cvacafe/sicca/config/../config/environment.rb:13
/usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require'
/usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:27:in `require'
/usr/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/dependencies.rb:495:in `require'
/usr/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/dependencies.rb:342:in `new_constants_in'
/usr/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/dependencies.rb:495:in `require'
/usr/lib/ruby/gems/1.8/gems/rails-1.2.6/lib/tasks/misc.rake:3
/usr/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:617:in `call'
/usr/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:617:in `execute'
/usr/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:612:in `each'
/usr/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:612:in `execute'
/usr/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:578:in `invoke_with_call_chain'
/usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'
/usr/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:571:in `invoke_with_call_chain'
/usr/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:588:in `invoke_prerequisites'
/usr/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:585:in `each'
/usr/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:585:in `invoke_prerequisites'
/usr/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:577:in `invoke_with_call_chain'
/usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'
/usr/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:571:in `invoke_with_call_chain'
/usr/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:564:in `invoke'
/usr/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:2019:in `invoke_task'
/usr/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1997:in `top_level'
/usr/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1997:in `each'
/usr/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1997:in `top_level'
/usr/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:2036:in `standard_exception_handling'
/usr/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1991:in `top_level'
/usr/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1970:in `run'
/usr/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:2036:in `standard_exception_handling'
/usr/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1967:in `run'
/usr/lib/ruby/gems/1.8/gems/rake-0.8.3/bin/rake:31
/usr/bin/rake:19:in `load'
/usr/bin/rake:19


Pues al igual que ustedes, quedé un poco chino con el error (a no ser que alguno de ustedes sea un Ruby developer :P), pero me puse a revisar unos archivos claves: /usr/lib/ruby/1.8/deprecated.rb en la línea 176 y /usr/lib/ruby/gems/1.8/gems/actionpack-1.13.6/lib/action_controller/routing.rb en la línea 994 (béndito sea el Software Libre xD) y descubrí que el problema era con la llamada a una tal función deprecate que esperaba un símbolo y no sé que diablos estaba recibiendo.

Le pregunté a un amigo (que programa conmigo el mismo sistema y no tenía el problema) por sus versiones de Ruby, Rails y las gemas. Teníamos todas las versiones exactamente iguales excepto la de Ruby; yo tenía la 1.8.7.174 y él tenía la 1.8.7.72.

Sí, aunque ustedes no lo crean yo aún uso Rails 1.2.6 con Ruby 1.8 y resulta que Debian Squeeze (testing al momento de escribir esto) me actualizó el paquete de Ruby estropeando la compatibilidad de Ruby y Rails. Sí, también sé que debo migrar a Rails 2 ¡¡¡cuanto antes!!!

Bueno la cuestión la solucioné de una manera relativamente fácil, purge mi instalación de ruby:

# aptitude purge ruby ruby1.8-dev ri ri1.8 rdoc rdoc1.8 irb irb1.8 ruby1.8-examples libreadline-ruby libopenssl-ruby libdbi-ruby libdbd-mysql-ruby libdbd-pg-ruby libdbd-odbc-ruby libdbd-sqlite3-ruby libpgsql-ruby libmysql-ruby

Cambié mis repositorios a los de Debian Lenny (estable para la fecha) (/etc/apt/sources.list):

deb http://ftp.us.debian.org/debian lenny main contrib non-free
deb-src http://ftp.us.debian.org/debian lenny main contrib non-free


Actualicé la lista de paquetes:

# aptitude update

Instalé nuevamente Ruby (pero la versión de Lenny):

# aptitude install ruby ruby1.8-dev ri ri1.8 rdoc rdoc1.8 irb irb1.8 ruby1.8-examples libreadline-ruby libopenssl-ruby libdbi-ruby libdbd-mysql-ruby libdbd-pg-ruby libdbd-odbc-ruby libdbd-sqlite3-ruby libpgsql-ruby libmysql-ruby

Apliqué retención a todos los paquetes anteriores (para que en una futura actualización no pase lo mismo):

# aptitude hold ruby ruby1.8-dev ri ri1.8 rdoc rdoc1.8 irb irb1.8 ruby1.8-examples libreadline-ruby libopenssl-ruby libdbi-ruby libdbd-mysql-ruby libdbd-pg-ruby libdbd-odbc-ruby libdbd-sqlite3-ruby libpgsql-ruby libmysql-ruby

Y volví a poner mis repos de Squeeze:

deb http://ftp.us.debian.org/debian testing main contrib non-free
deb-src http://ftp.us.debian.org/debian testing main contrib non-free


Ahora tengo mi obsoleto y anticuado Ruby 1.8.7.72 pero que me funciona de maravillas con Rails 1.2.6 xD

Cambio y fuera

Fluxbox con esteroides en Debian

sábado, septiembre 19, 2009

Fluxbox siempre me había parecido un gestor de ventanas genial, pero consideraba que aún le faltaban algunas cosas para ser un entorno de escritorio "serio", capáz de darle competencia a GNOME... Hasta hoy.

Me puse a experimentar con la mini Acer y dije... "¿Por qué no? Vamos a meterle Fluxbox a ver que tal corre" y pues, dejénme decirle que los resultados que obtuve son simplemente impresionantes.

Al momento de hacer esto lo que tenía en mente era lograr un entorno de escritorio 100% funcional (tanto o más que GNOME) pero manteniendo siempre el bajo consumo de recursos y pensando siempre en una frase que leí una vez (si mal no recuerdo en la descripción del paquete Fluxbox para Debian):

Si quiere que su escritorio se parezca a Windows entonces no use Fluxbox

Primero vamos a instalar los paquetes básicos:
# aptitude install fluxbox conky eterm pcmanfm gqview audacious wbar
Explico para qué cada cosa:

  • fluxbox: Creo que es obvio ¿no? El gestor de ventanas
  • conky: Un monitor del sistema bien ligero y configurable
  • eterm: Un emulador de terminal ligero (usado en Enlightenment) o xterm para los más rudos
  • pcmanfm: Un explorador de archivos rápido y liviano. Para no explicar mucho diré que es un Nautilus a dieta xD. También podemos instalar thunar, el explorador de archivos de XFCE
  • gqview: Un visor de imágenes ligero. También podemos usar eog (el visor de imágenes de GNOME)
  • audacious: Un reproductor de música super liviano y parecido a Winamp (para los nostálgicos :'( )
  • wbar: Un dock que imita la famosa barra de Mac OS X. Útil para usarla como lanzador de aplicaciones

Nuevamente resalto que la selección de las aplicaciones se hizo en base a la premisa de "aplicaciones ligeras y de bajo consumo", sin embargo podemos instalar cualquier otra aplicación que nos guste: pidgin, inkscape, deluge, etc, etc, etc.

¡OJO! Si no tenemos instalado GNOME necesitaremos instalar unos paquetes adicionales; pero seré sincero... NO he hecho la prueba desde una instalación sin GNOME. Me imagino que instalando los paquetes (y sus dependencias) es más que suficiente pero no puedo asegurar. Si no funciona así, griten y yo intentaré probar para actualizar el post con el procedimiento correcto (o si prueban ustedes y me dicen, mejor xD). Entonces, si no tenemos problemas de espacio en el disco recomiendo instalar:

# aptitude install gnome-desktop-environment

O si son más aventureros y desean experimentar, solo instalamos:

# aptitude install gnome-power-manager gnome-settings-daemon network-manager

Bueno, vamos ahora con la parte divertida.

Configuremos Conky

Conky como dije anteriormente es un monitor de sistema muy liviano. Allí podemos monitorear cientos de parametros de nuestro equipo y se ve bastante bien con Fluxbox :)

Lo primero que debemos hacer es habilitar el soporte de la extensión Double Buffer (DBE) del servidor X para evitar el parpadeo, ya que sin ésta no logrará actualizar la pantalla con suficiente rapidez. Para ello, vamos al archivo /etc/X11/xorg.conf y agregamos una línea con Load "dbe" en la sección Section "Module". Debería verse algo así:

Section "Module"
    Load           "dbe"
    Load           "extmod"
    Load           "type1"
    Load           "freetype"
    Load           "glx"
EndSection

Luego copiamos el archivo de configuración de ejemplo que viene con el Conky a nuestra carpeta personal:

$ cp /etc/conky/conkyrc.conf ~/.conkyrc

y lo abrimos con nuestro editor de texto favorito. Se darán cuenta que el archivo está dividido en dos partes. La primera contiene las opciones de configuración del programa (alteran su comportamiento). La segunda define las variables, el texto, y los gráficos que se mostrarán en pantalla.

La cantidad de variables y opciones que se pueden manejar son muchísimas, así que dejo la lista completa de opciones para configuración y de variables a monitorear. Si eso no es suficiente, aquí pueden ver unos cuantos screenshots con sus respectivos archivos de configuración para que echen a volar su imaginación y además les dejo mi archivo de configuración (hoy me siento benevolénte :P)

# Conky, a system monitor, based on torsmo
#

alignment top_right
background no
border_width 1
cpu_avg_samples 2
default_color white
default_outline_color white
default_shade_color white
draw_borders no
draw_graph_borders yes
draw_outline no
draw_shades no
use_xft yes
xftfont DejaVu Sans Mono:size=10
gap_x 5
gap_y 60
minimum_size 5 5
maximum_width 200
net_avg_samples 2
no_buffers yes
out_to_console no
out_to_stderr no
own_window no
own_window_class Conky
own_window_type desktop
stippled_borders 0
update_interval 1.0
uppercase no
use_spacer none
show_graph_scale no
show_graph_range no

TEXT
$nodename # $sysname $kernel on $machine
$hr
${color slate grey}${time %a, }${color }${time %d %b %G}
${color grey}Uptime:$color $uptime_short
${color slate grey}Kernel: $kernel
${color black}CPU:
$color ${cpu cpu0}% ${cpubar cpu0 4}
$color ${cpu cpu1}% ${cpubar cpu1 4}

${color grey}RAM:$color $mem / $memmax
$color ${memperc}% ${membar 4}
${color grey}Swap:$color $swap / $swapmax
$color ${swapperc}% ${swapbar 4}

${color grey}Processes:$color $processes  ${color grey}Running:$color $running_processes
$hr
${color grey}File systems:
 / $color${fs_used /}/${fs_size /} 
${fs_bar 6 /}
${color grey}Networking:
Up:$color ${upspeed eth0} ${color grey} - Down:$color ${downspeed eth0}
$hr
#${color grey}Name              PID   CPU%   MEM%
#${color lightgrey} ${top name 1} ${top pid 1} ${top cpu 1} ${top mem 1}
#${color lightgrey} ${top name 2} ${top pid 2} ${top cpu 2} ${top mem 2}
#${color lightgrey} ${top name 3} ${top pid 3} ${top cpu 3} ${top mem 3}
#${color lightgrey} ${top name 4} ${top pid 4} ${top cpu 4} ${top mem 4}

Configuremos Wbar

Wbar es un lanzador de aplicaciones que emula algunas características de la barra de Mac OS X. Es altamente configurable y la más decente que he visto hasta ahora... ¡Toma eso Gnome-Do!

Al igual que Conky trae un archivo de configuración de ejemplo y solo debemos copiarlo a nuestra carpeta personal con el nombre .wbar:

$ cp /usr/share/wbar/dot.wbar ~/.wbar

El archivo define cada uno de los lanzadores de la barra tiene el siguiente formato:

i: /ruta/del/icono
c: comando_a_ejecutar
t: Título del lanzador


La primera entrada corresponde a la imagen de fondo de la barra y no debe llevar comando.

Recomiendo hacer una selección de los iconos que desea para cada lanzador y colocarlos en una carpeta. A continuación imprimo mi archivo de configuración de lanzadores (en mi caso hice la selección de los iconos y los coloque en una carpeta llamada personal en /usr/share/wbar/iconpack/:

i: /usr/share/wbar/iconpack/wbar.osx/osxbarback.png
c:
t: /usr/share/wbar/iconpack/wbar.osx/font/16

i: /usr/share/wbar/iconpack/personal/gnome-fs-home.png
c: pcmanfm
t: Explorador de archivos

i: /usr/share/wbar/iconpack/personal/mozicon50.xpm
c: firefox
t: Firefox

i: /usr/share/wbar/iconpack/personal/gnome-terminal.png
c: xterm
t: Terminal

i: /usr/share/wbar/iconpack/personal/pidgin-menu.xpm
c: pidgin
t: Pidgin

i: /usr/share/wbar/iconpack/personal/text-editor.png
c: gedit
t: Gedit

i: /usr/share/wbar/iconpack/personal/audacious-32.xpm
c: audacious
t: Audacious

i: /usr/share/wbar/iconpack/personal/xchat.png
c: xchat
t: XChat

La otra parte interesante del wbar son los argumentos que se le pasan al momento de ejecutarlo. A continuación la lista de opciones:

Opciones
 -config: ruta del archivo de configuración (ej: $HOME/.wbar)
 -above-desk: para ejecutarlo encima del escritorio
 -idist i: distancia entre los iconos (ej: 1)
 -isize i: tamaño de los iconos (ej: 32)
 -zoomf i: factor de zoom (ej: 1.8)
 -jumpf i: factor de salto (1.0 - 0.0)
 -pos|p: posición (top | bottom | left | right | center)
 -dblclk i: milisegundos para el double click (0: un solo clic)
 -bpress: los iconos parecen presionados al darle clic
 -vbar: barra vertical
 -balfa i: transparencia de la barra (0-100)
 -falfa i: transparencia de la barra cuando no tiene foco (0-100)
 -nofont: deshabilita el dibujado de las fuentes

Los argumentos que le paso al wbar los pueden ver en el archivo startup de Fluxbox un poco más abajo.

Configuremos Fluxbox

~/.fluxbox/init

Este archivo maneja la configuración general de Fluxbox. Podemos definir la posición, el ancho y los elementos que deseamos en la barra de tareas. El archivo es extenso y con muchas opciones, así que mostraré un pedazo de mi archivo con las opciones más relevantes. Para información más detallada ...

session.screen0.toolbar.alpha: 255                    # Transparencia de la barra de herramientas
session.screen0.toolbar.widthPercent: 100             # Ancho de la barra
session.screen0.toolbar.visible: true                 # Mostrar la barra de tareas
session.screen0.toolbar.tools: prevworkspace, workspacename, nextworkspace, iconbar, systemtray, clock  # Herramientas que deseamos motrar (y el orden en que aparecerán)
session.screen0.toolbar.placement: BottomCenter       # Posición de la barra
session.screen0.toolbar.autoHide: false               # Ocultar automaticamente
session.screen0.workspacewarping: true                # Cambiar una ventana de escritorio al moverla hacie los extremos laterales
session.screen0.workspaces: 4                         # Cantidad de escritorios
session.screen0.strftimeFormat: %d %b, %a %02k:%M:%S  # Formato de la hora del reloj
session.screen0.workspaceNames: Workspace 1,Workspace 2,Workspace 3,Workspace 4,  # Nombre de cada escritorio

# Ejecutar el wbar con un delay de 5 seg para esperar que carguen todos los demás programas
session.screen0.rootCommand: sleep 5 && wbar -pos left -above-desk -vbar -jumpf 0.0 -zoomf 1.5 -idist 1 -bpress -config $HOME/.wbar

El orden en que se definan las herramientas será el orden que tengan en la barra. Las posibles herramientas son: workspacename, prevworkspace, nextworkspace, iconbar, systemtray, prevwindow, nextwindow y clock

~/.fluxbox/startup

Aquí definimos que aplicaciones se ejecutan al inicio del sistema. Mostraré mi archivo y comentaré cada opción.

#!/bin/sh
#
# fluxbox startup-script:
#
# Lines starting with a '#' are ignored.

# Change your keymap:
xmodmap "/home/satanas/.Xmodmap"

# Applications you want to run with fluxbox.
# MAKE SURE THAT APPS THAT KEEP RUNNING HAVE AN ''&'' AT THE END.

conky -d -b &
nm-applet --sm-disable &
gnome-power-manager --sm-disable &
gnome-settings-daemon &

# And last but not least we start fluxbox.
# Because it is the last app you have to run it with ''exec'' before it.

exec fluxbox
# or if you want to keep a log:
# exec fluxbox -log "/home/satanas/.fluxbox/log"


conky -d -b: El monitor del sistema ejecutado con double buffer y en segundo plano
nm-applet: El Network Manager de GNOME que nos permite manejar nuestras redes
gnome-power-manager: El applet de GNOME que entre otas funciones nos muestra el estado de la batería
gnome-settings-daemon: El demonio de configuración de GNOME. Esto es para que podamos ver los iconos y el tema de GNOME sin problemas (necesario para pcmanfm)
wbar: La famosa barrita para lanzar aplicaciones ;)

~/.fluxbox/keys

En este archivo configuramos las combinaciones de teclas (atajos de teclado) de nuestro entorno de escritorio. Fluxbox denomina a la tecla Alt como Mod1 y a la innombrable (la tecla Super o Win) como Mod4. La sintaxis del archivo es:

[teclas]: [acción] [parámetros]

Una lista completa de posibles acciones podemos verla en http://fluxbox.sourceforge.net/docbook/en/html/x359.html

Algunos atajos útiles serían:

  • Cambiar de ventana con Alt + Tab
    Mod1 Tab :NextWindow
  • Cambiar al escritorio 1 con Ctrl + F1 (se debe repetir para cada escritorio que tengamos)
    Control F1 :Workspace 1
  • Abrir un terminal con Alt + F1
    Mod1 F1 :Exec eterm
  • Abrir un diálogo de "Ejecutar" con Alt + F2
    Mod1 F2 :Exec fbrun

Resultado


Un agradable y eficiente escritorio como el que se ve en las fotos :)





Un último tip es habilitar el plugin StatusIcon de Audacious (tal como se ve en la imagen de abajo) para que podamos minimizarlo a la bandeja de sistema (haciendo clic en el icono).


¡Uff! con tanto configurar y escribir ya me dió sueño, así que me voy. Hasta la próxima

Otras referencias:
[1] http://www.gentoo.org/doc/es/fluxbox-config.xml
[2] http://fluxbox.sourceforge.net/docbook/en/html/chap-toolbar.html
[3] http://debianitas.net/doc/minicomos/Todo%20Sobre%20FLUXBOX/html/fluxbox.html
[4] http://www.estrellateyarde.es/so/fluxbox