En los ultimos dias he estado como loco programandoy probando algunas cosas que he estado haciendo, de momento he dejado de ladito el desarrollo de christine y gpkg, por el momento tengo que dedicarle un poco mas de tiempo a lo que me ha de dar de tragar, como bien me dijo el buen visor: Primero comer que ser cristiano en fin, prefiero dedicar un poco mas de tiempo las cosas que me van a redituar un poco de dinero y si tengo tiempo le dedico a christine y gpkg.

La tesis me tiene un poco atareado, con eso de que hay que cambiarle todo para que sea mas "entendible", menos técnica y que aun asi describa todo lo que yo necesito que describa, aunque encuentro esto bastante dificil, pues mi tesis trata sobre desarrollo de aplicaciones en Python utilizando Pygtk y Glade y hablar de un lenguaje de programacion y sus herramientas resulta ser por naturaleza bastante técnico. En fin... tengo que hacerla.

Por otro lado he estado trabajando en un pequeño proyecto, que si todo sale como yo espero en un par de semanas a mas tardar estará montado y podrá por fin ver la luz. Esto me recuerda, que vaya como son las cosas. Hace un par semanas recordaba mi primer lenguaje de programacion: PHP, curiosamente este nuevo proyecto esta siendo desarrollado en PHP, y vaya que si despues de poco mas de 1 año no moverle a PHP se me estaban olvidando varias cosas, sobre todo por el modo de trabajo de Python. Por ejemplo, estoy acostumbrandome a que una cadena por si misma tenga sus metodos y no a llamar funciones para modificar la cadena.

En fin, el chiste es que he estado haciendo consultas seguidas a php.net en busca de documentación, y aunque me parece definitivamente un poco mas dificil la programacion en PHP sobre todo por las vueltas que hay que dar, me recuerda buenos tiempos y me divierte.

EspacioLinux.org ha publicado un articulo sobre Gpkg. Me ha gustado el articulo y describe de excelente manera las nuevas caracteristicas de Gpkg en su version 0.4

Pueden leer el artículo aqui: Gpkg 0.4, el avance desde la primera versión

No se si sea yo o si es sourceforge.net, el caso es que no puedo subir los putos cambios que he hecho al código de gpkg al CVS desde hace unos 3 o 4 dias . Cosa que no me gusta.

Por fin, depues de 4 meses de trabajo se me da el poder liberar gpkg en su version 0.4. gpkg incluye nuevas chucherias y ha mejorado algunas otras, a continuacion una lista de lo que hace.

• Listar los paquetes instalado y los que han sido removidos.
• Busquedas entre los paquetes
• Mostrar/Ocultar paquetes en las listas durante la busqueda
• Instalar/Actualizar/Remover sin congelarse mientras pkgtools esta trabajando.
• Instalación/Actualización/Desinstalación multiple de paquetes
• La busqueda de archivos entre paquetes es mas rapida
• La busqueda de archivos permite escojer en que paquetes se va a realizar la busqueda.
• Instalación via Drag and Drop desde Nautilus
• Instalación por via de comandos (gpkg -i paquete1 paquete2 ..)
• Visor de logs.
• Preferencias
• La ayuda se muestra con Yelp (o el visor de ayuda preferido en Gnome)
• Busqueda e Intalación de paquetes con swaret y slapt-get.

Update: Se han hecho unas correcciones, unos bugs que se me habian barrido y que fueron detectados por Paco Revilla Gpkg ya esta disponible para descarga en Sourceforge.net. Se encuentra en codigo fuente y empaquetado para Slackware Linux.

Pues yo creo que lo que se necesitaba hacer para gpkg 0.4 ya esta casi todo hecho. En estos ultimos dias he estado trabajando en la documentación, que ahora se verá por medio de yelp. He corregido algunos pequeños bugs y he terminado de traducir algunas lineas de es_ES.

Espero dentro de la proxima semana liberar gpkg 0.4 por fin.

gpkg esta proximo a ser estable, pero aun hay cosas por hacer, una de las tareas pendientes en la internacionalización, el objetivo es hacer que gpkg hable los idiomas mas populares (si no todos), tu puedes ayudar obteniendo el archivo gpkg.pot del cvs y traduciendolo a tu idioma de origen.

Obteniendo el codigo del cvs:

tambien se puede por medio del cvs browser: http://cvs.sourceforge.net/viewcvs.py/gpkg

O mas facil, por medio del tarbal nocturno.

http://cvs.sourceforge.net/cvstarballs/gpkg-cvsroot.tar.bz2

Esta es otra version aun en desarrollo de gpkg, algunos cambios son:

• Soporte para instalacion usando Drag & Drop sobre la lista de paquetes instalados.
• Inicio mas rapido
• Error en el scroll de la ventana de instalación (provocado por vte y el scrollwindow)
• Soporte para slapt-get y swaret

Aun es una version en desarrollo pero agradeceria muchisimo si los slackeros lo prueban y me comentan los errores que puedan llegar a encontrar.

Source tgz Slackware

Esta semana me la he pasado echando la weba, y poco he tocado el código de Gpkg, principalmente porque los pinches bindindg de VTE me han estado dando unos problemas con el metodo vte.fork_command(), aunque no estoy seguro bien por que será el fallo.

Lo poco que he hecho en esta semana ha sido reescribir lo que habia perdido por un estupido error mio, y dentro de estas cosas que ya habia borrado estaba una clase en la que se obtenia la información para cada paquete. Anteriormente se utilizaba la clase packages, y se obtenia la información por medio de metodos como

pero esto hace que por cada una de estas cosas tenga que abrir el indice y hacer una iteración buscando y acomodando las cadenas, que para un solo paquete no es nada dificil, pero para un sistema de unos 571 paquetes (como lo tengo yo) pues hace que la cosa se alente al generar las listas, pues tiene que abrir y cerrar el indice unas tres veces por paquete. Obviamente esto no es bueno, y si lo escribí asi en un principio fue porque lo hice de a putazo para ver como lucia la cosa.

La clase que escribi ahora se crea enviando el nombre del paquete como parametro, y se pueden obtener los valores como si fueran parte de un diccionario:

Obviamente no voy a meter toooooda la informacion del paquete en una sola instancia y de a putazo, porque al hacer la iteración (cuando se generan las listas) hago mas pesada la cosa, asi que para cosas como obtener el indice o el script se necesita pedirlos como metodos.

Esto hace que gpkg trabaje un poco mas rapido, claro que con respecto a gpkg-0.2 no hay una diferencia notable, pero es porque gpkg-0.3.x ahora tiene que crear mas widgets y consultar cosas con gconf, inicia el programa con libgnome, etc. pero no tarda mucho en inciar.

Gpkg cuenta con el parametro -u con el cual se pueden actualizar la de paquetes instalados sin tener que mostrar toda la gui, algo util cuando es la instalación de gpkg. Generar la lista desde 0 toma unos ~10 segundos:

y el actualizarla a partir de una lista ya generada toma entre 1 y 5 segundos.

Ahora, lanzar gpkg con todo y todo (inicial la aplicacion con libgnome, construir la venta principal, el resto de los widgets, actualizar listas, etc..) toma en un principio (con una lista ya generada) entre 5 y 10 segundos. pero que estando en cache puede reducirse a 2~5 segundos.

El parametro -e es para terminar la aplicación una vez que se haya generado todo (incluso mostrar la ventana principal).

Bueno, es en lo que he estado trabajando esta semana sobre gpkg, en la que sigue le daré soporte para swaret y veré de que forma resuelvo ese problemita que tengo con los bindings de VTE.

Gpkg Cuenta ahora con un soporte para slapt-get. De momento no es nada comparable con lo que puede hacer GSlapt (de los mismos desarrolladores de Slapt-get).

Dado que Gpkg debe ser pequeño, solo he agregado una opcion mas a la busqueda de paquetes, ahora, al hacer una busqueda de paquetes tambien se muestra la opcion de "buscar en:" y de ahi escogemos slapt-get y pulsamos el boton de busqueda.

De ahi nos parseará la salida de la busqueda como una lista, donde podremos seleccionar los paquetes que queremos instalar, y entonces le damos "install" y el paquete se ha de instalar usando slapt-get.

Ahora, por hay que seleccionar un menu la opcion "slapt-get" ??, facil, porque tambien quiero darle soporte a swaret. Me he dado cuenta de que gpkg no podrá adentrarse un poco mas si no hace esas labores de instalación tambien, y como no pienso reinventar la rueda, pues es mejor utilizar algo que ya existe, no creen?.

Yer!!!! Finally!!!, absolute!!!!!, por fin pude acomodar gpkg con las autotools . Ahora instalar gpkg no es de un simple:

a un (mas largo pero personalizable):

Y que es lo que se logra con esto?. Algunos archivos en python son configurados, sobre todo los que definen donde se van a localizar ciertos archivos (imagenes, *.glade, logs, locales, etc...).

Ademas que de esta manera la instalación de gpkg es mas amigable, mas común.

He creado un paquete de a como lo tengo ahorita, que si bien no me ha fallado en mis pruebas me reservo a que esta en "pruebas", aun es código en trabajo y puede tener errores. Sin embargo puedes por favor probarlo y si encuentras bugs, podrias notificame?

Codigo fuente: gpkg-0.3.2.tar.gz Paquete para Slackware 10.2 : gpkg-0.3.2-noarch-2mkz.tgz

Cuando escribimos algun script en Python y pensamos en distribuirlo por lo general utilizamos el modulo "DistUtils" de Python que nos permite instalar los modulos y algunas cosas extra. Pero distutils no nos da la flexibilidad de un script como el "configure", para poder definir donde se han de instalar nuestros archivos de interface gráfica, o las imagenes, cual será el directorio en donde se guardara la configuracion (en caso de no usar Gconf) o donde se guardaran los logs, etc..

Para esto tenemos entonces las fenomenales Autotools . Ahora, todo mundo ha de pensar, no mames.... si los scripts en Python no son algo compilado!!!. No importa si es compilado o no, el chiste es que el script se pueda configurar al gusto del cliente. Supongamos que en nuestra clase "pixmaps" definimos donde vamos a guardar las imagenes. Lo mas obvio seria ponerlo directamente:

Que si bien __Deberia__ de ser la path correcta, puesto que un programa deberia ser instalado en "/usr" no en "/usr/local", no todos quieren que sea así., habrá alguien que lo quiera instalar en su $HOME.

Utilizando Autotools podemos definir estas cosas utilizando el configure y los Makefile. He aqui la cosa, primero analicemos el script configure.ac con el que despues elaboraremos el dichoso script "configure":

Lo primero es iniciar nuestro escript, lo interezante es que aqui mismo definimos variables como "PROGRAM_NAME" y "VERSION" que despues mandamos a los makefile con "AC_SUBST()". Lo que sigue es declarar los scripts que se han de crear (usando AC_CONFIG_FILES), como el mismo Makefile y el de nuestro paquete que se encuentra en el directorio "paquete", para poder hacer esto necesitamos que exista un archivo con el mismo nombre pero con un ".in" al final, es decir, en vez de tener "Makefile", tendriamos "Makefile.in"

Para poder crear los makefile, debemos tener un Makefile.am en nuestro directorio base, y uno en cada subdirectorio, nuestro Makefile.am en nuestro directorio base deberia ser algo asi (muuuy, pero muy basicamente):

Hay muchas cosas que estoy omitiendo aqui, pero que podremos ver en el siguiente Makefile. Si nos damos cuenta tenemos una variable llamada SUBDIRS, que define los directorios en los que "make" y "automake" van a entrar y hacer lo suyo.

Ahora, el Makefile.am que debe estar en el subdirectorio "paquete" deberia contener esto:

A la hora de que se ejecute "make" Make va a ejecutar las reglas especificadas para all-am (crear los nuevos archivos a partir de templates), dentro de esto encontramos que se manda a llamar la variable "edit", que en realidad ejecuta sed y sustituye las variables por la version ya "expandida".

Entonces para poder generar el script "configurado" tenemos que crear un template del mismo archivo con un ".in", si nos damos cuenta seria pixmaps.py.in, que deberia ser asi:

A la hora de ejecutar "make" este de acuerdo al template creará el nuevo script sustituyendo las variable sencontradas, las cuales estan encerradas entre arrobas "@". asi el usuario puede decidir donde el programa ha de buscar los pixmaps. .

Un error seria pedir que "configure" haga esto, pues se pude hacer que configure nos genere los nuevos archivos solo sustituyendo las variables, pero no expande las variables como "sysconfdir","datadir", e incluso, si "prefix" esta vacio lo marcara como NONE. Lo cual no es muy bueno que digamos, podemos utilizarlo para sustituir pequeñas variables que definimos ahi mismo como PROGRAM_NAME y VERSION.

Nota: las _at_ son en realidad arrobas, la cosa esta me parsea y me quita las arrobas

Hace unos dias me llegó mi librito The official GNOME 2 Developers Guide, muy pero muy buen libro, aunque todo esta en ingles y todo está orientado al lenguaje C es muy didáctico pues practicamente todo esto aplica a programas hechos con Python y PyGTK + Gnome. Pues en uno de los capitulos (que no recuerdo ahorita, pero que anda por la linea 325 (o por ahi cerca), habla sobre las autotools.

Y me surgió el gusanito de leer sobre las autotools porque me he fijado que aplicaciones hechas con mono como , que se supone no son compiladas (en cierta forma) pasan por las autotools. En Python pues.. en realidad no hay cosas compiladas, pero si hay cosas en las que las autotools nos pueden ayudar, sobre todo a la hora de dar la flexibilidad al usuario de donde se han de instalar los pixmaps, o los archivitos .glade de la UI, o donde se han de guardar los archivos de configuración, etc...

Esto se logra en gran medida utilizando la expasión de variables, con sed y despues ejecutando el clasico "make".

Debo decir que apenas me estoy empezando a empapar sobre el tema, pero se ve muuuy, pero muy prometedor .

Yep, ayer me puse a acomodar el script de instalacion (setup.py) y el MANIFEST.in de gpkg y me he montado el paquete de gpkg 0.3.1 para Slackware Linux 10.2, aunque deberia funcionar tambien en slackware 10.1, pero para mas seguro, se pueden instalar directamente o crear el paquete del codigo fuente.

Paquete para Slackware Linux 10.1: gpkg-0.3.1-noarch-1mkz.tgz Tarball source dist: gpkg-0.3.1.tar.gz

Nota: Esta no es de ninguna manera una version "estable", pero sirve para probar. Para aquellos que quieran hacer el favor de traducir cadenas proximamente pondré los Po en el CVS