Los reportes que se pueden realizar son de personas y asistencias (aquí y aquí tienen ejemplos). Éstos se producen en formato PDF. Lamentablemente no hay una forma de imprimir los reportes directamente, por lo que puede ser complicado para usuarios inexpertos.

Al final, estoy utilizando iTextSharp para generar los PDFs, no MonoReporter, que si bien actualmente puede generar reportes básicos, decidí por el momento utilizar algo ya hecho y maduro. Con MonoReporter (que utiliza GtkPrint) sí podría imprimir el reporte directamente, o ver previsualizaciones. Pero bueno, será algo a hacer más adelante.

Para realizar reportes más personalizados, tengo pensando añadir a Zaspe# posibilidades de extensión, con Mono.Addins. Estaría bueno poder definirlos en un lenguaje tipo Boo (ya que los reportes con iTextSharp habría que diseñarlos con código fuente, nada gráfico), de sintaxis parecida a Python, y sin la necesidad de compilar el código. Así sería muy fácil incluso añadir funcionalidad en forma de plugin.

En la wiki hay una página TODO donde voy anotando las características que me gustaría añadir más adelante.

Un screenshot simple del diálogo para generar los reportes:

Si, muy simple y limitado.

En los releases anteriores, nunca subía el código fuente de la versión, aunque sí hacía un copia de la revisión en ‘trunk’ correspondiente a la versión liberada en la carpeta ‘tags’. Esta vez pueden bajarse en un archivo comprimido los binarios y los fuentes.

Hay algunas cuestiones a tener en cuenta con respecto a la versión de Gtk# en Windows, que se pueden leer en el archivo README de los binarios. En GNU/Linux funciona bien en Ubuntu Hardy Heron con Gtk# 2.12.

Esta aplicación me sirvió más a mí para aprender Gtk con Mono que al usuario que en un principio me había pedido este desarrollo.

En fin, Sebastián me mencionó algunos bugs que tenía la versión 0.0.2, de lo que era consciente, y ya estaban corregidos en trunk. Por lo tanto, decidí realizar este release. El proyecto está bastante parado, el problema, como dije, son los reportes. Hubo avances con MonoReporter, pero todavía nada suficiente como para poder generar listados de personas, de eventos, asistencias, etc.

Mi idea era hacer algo que no sólo me sirva a mí, sino que lo pueda usar otra persona también. Cuando le comenté la idea a Nacho, sobre un lenguaje basado en XML para describir el reporte, me propuso leer un SVG, hecho con Inkscape por ejemplo… así me ahorraría un futuro diseñador de reportes. Eso es lo que he hecho.

MonoReporter entonces lee de un SVG hecho con Inkscape (lo aclaro porque sobre este software hice las pruebas), y lo transforma a instrucciones para dibujar con Cairo y GtkPrint (el nuevo sistema de impresión de Gtk+). Es posible, por ejemplo, exportar directamente a PDF, o mostrar el diálogo de impresión, tanto en GNU/Linux como Windows (previa instalación de los runtimes de gtk-sharp que se pueden encontrar en la web de zaspe#). A esto lo realiza en forma nativa.

Para leer el XML (SVG), simplemente uso las clases en el namespace System.Xml. No utilizo ninguna librería externa. He probado una, SvgNet, un proyecto poco activo (último release en el 2003). Y me he dado cuenta de que tenía que adaptarlo mucho… así que opté por crear mis propias clases de lectura del SVG, que terminó siendo un trabajo bastante sencillo en realidad.

Debido a algunas limitaciones que tengo en Windows (como los bindings de Cairo sólo disponibles para el profile 1.0), el diseño en general de las clases no es el mejor, o por lo menos el que me hubiese gustado.

Este es un ejemplo de uso de MonoReporter con C# (en realidad, se puede utilizar con cualquier lenguaje de .NET):

using System.Data;
using MonoReporter;

...

Report report = new Report("PruebaMonoReporter", "test.svg");
report.Data["titulo"] = "Listado de personas";

DataTable personsTable = new DataTable();

DataColumn[] columns = new DataColumn[4];
columns[0] = new DataColumn("nombre");
columns[1] = new DataColumn("apellido");
columns[2] = new DataColumn("dni");
columns[3] = new DataColumn("direccion");
personsTable.Columns.AddRange(columns);

DataRow d1 = personsTable.NewRow();
d1["nombre"] = "Milton";
d1["apellido"] = "Pividori";
d1["dni"] = "99999999";
d1["direccion"] = "dirección";
personsTable.Rows.Add(d1);

d1 = personsTable.NewRow();
d1["nombre"] = "Pepe";
d1["apellido"] = "Biondi";
d1["dni"] = "11111111";
d1["direccion"] = "alguna dirección";
personsTable.Rows.Add(d1);

d1 = personsTable.NewRow();
d1["nombre"] = "Juan";
d1["apellido"] = "Sanchez";
d1["dni"] = "33333333";
d1["direccion"] = "otra dirección";
personsTable.Rows.Add(d1);

report.DataTables["personas"] = personsTable;

report.Run(myWindow);

DataTable es una clase del namespace System.Data.

Report es una clase de MonoReporter, la principal. En las primeras lineas se crea un nuevo reporte con un título dado, y un archivo SVG de donde leer el diseño del reporte. La propiedad Data devuelve un Hashtable, en el que podemos setear el texto que queramos al elemento SVG indicado por la clave. En este caso, se está diciendo que al momento de generar el reporte, al elemento con id (lo cambiamos desde Inkscape) “titulo” le asigne el valor “Listado de personas”.

Una vez creado el DataTable, le indicamos la fuente de datos para la “tabla” llamada “personas”. Una “tabla” es un concepto inventado, que se forma creando varios elementos de texto en Inkscape, tantos como columnas haya, y dándole a cada uno el nombre de la columna (que definimos en el DataTable). Luego se los agrupa, y a esa agrupación se le coloca un nombre. El nombre en este caso es “personas”.

De esta forma cuando MonoReporter encuentra un layer con sólo nodos “text”, sabe que se trata de una tabla. Este es el archivo PDF final que genera el código de arriba.

Quedan muchas (muchísimas) cosas por hacer, a tal punto de que ni siquiera es usable: por el momento se pueden generar reportes de una sola página Algunas cosas que faltan por hacer:

• Soporte para reportes largos (de más de una página).
• Soporte para más elementos gráficos de SVG (por ahora reconoce rectángulos, líneas y texto).
• Mayor nivel de personalización: por ejemplo, el espacio entre filas no se puede cambiar.
• Soporte para la inclusión de imágenes.
• Etc etc etc…

Algunas limitaciones:

• A los textos sólo se los puede redimensionar aumentando su tamaño de fuente, o sea, sin utilizar las flechas.
• Raramente, algunos colores son bien leidos, pero otros no, como el verde.
• Y muchas más…

El código fuente se encuentra aquí, en el mismo repositorio que Zaspe#. Está bajo la GPLv3.

Si alguien tiene algún comentario, alguna mejora o sugerencia para encarar esto mejor… bienvenido sea!

Funciona en GNU/Linux con Mono (yo lo estoy probando con la versión 1.2.3 que viene en Ubuntu Feisty) o en Windows con .NET Framework 2.0 y el runtime de gtk-sharp 2.10 (que se lo pueden bajar de la página del proyecto).

Si les interesa probarlo, se pueden bajar los archivos desde la página de descargas del proyecto.

Una aclaración para el uso: cuando lo ejecutan, verán al inicio la lista de asistencias vacía. Para que se habilite tienen que ingresar por lo menos una persona, y por lo menos un evento anterior a la fecha actual (ya que no tiene sentido ingresar las asistencias para un evento futuro). Si a alguien le es útil algo así, y tiene ideas para mejorarlo, por favor, están invitados a dejar un comentario en este post, o un issue.

ZaspeSharp es un programa muy simple para manejar las asistencias de personas a determinados eventos, y apunta, en un futuro, a generar una variedad de informes sobre estos datos. Está desarrollado con C#, principalmente en Mono bajo GNU/Linux. Sin embargo también funciona bajo Windows con el .NET Framework 2.0. En éste último caso es necesario bajarse el runtime de Gtk# 2.10, que se encuentra en la página de descargas en la web del proyecto.

Ojalá sirva para alguien más que para el director del coro Monseñor Zaspe. Supongamos que alguien se interesa en el proyecto y desea hacer unas modificaciones. Esta persona conoce mucho sobre la plataforma .NET, y es programador C#. Trabaja en Windows con SharpDevelop. Imaginemos cuatro personas más similares a esta última: la primera maneja muy bien Visual Studio 2003 y es el que usa; la segunda tiene Visual Studio 2005; la tercera trabaja en GNU/Linux con MonoDevelop; y la cuarta prefiere modificar los archivos de código fuente con GVim y compilar con NAnt o las Autotools. ¿Cómo satisfacer a todas ellas?

Antes, en ZaspeSharp, incluía los archivos de solución y proyectos para MonoDevelop y SharpDevelop. Con eso cubría ambas plataformas: Windows y GNU/Linux. El problema es que como trabajo principalmente en éste último, a veces los archivos de SharpDevelop quedaban rotos al no incluir algún fichero necesario.

La solución se llama Prebuild. Y aunque todavía tiene un camino por seguir, se puede decir que funciona. Lo que se hace es escribir un archivo XML con los datos de la solución. Luego se ejecuta el programa (que está incluido en el SVN de ZaspeSharp) indicándole este archivo y el target, que puede ser MonoDevelop, SharpDevelop (1.x o 2.x), NAnt, Autotools, Visual Studio 2002, 2003 y 2005.

Todo esto parece impresionante, pero sin embargo tuve algunos problemas. Se ve que los chicos encargados del desarrollo de Prebuild trabajan más con otras herramientas distintas a MonoDevelop, ya que algunas opciones no se seteaban bien para éste. Está bien… uso la versión 0.14 que salió hace poco, pero algunas características creo que estaban en la 0.13. Así que modifiqué el código encargado de generar los archivos de éste IDE para que soporte algunas de estas cosas. Los archivos generados para MonoDevelop (uso la versión 0.14) y para SharpDevelop (versión 2.2) son correctos. No lo tengo para testear, pero seguramente funciona bien para todas las versiones de Visual Studio. Si apuntamos a NAnt hay que modificar algunas cositas en el archivo .build generado para un proyecto de ZaspeSharp, que es un poco complejo, lo admito. Y finalmente, no funciona si intentamos generar los archivos para las Autotools, seguramente por la complejidad de ese proyecto que mencioné. Además, habría que ver si estoy seteando correctamente las opciones en el archivo XML… esta es otra contra de Prebuild: documentación cero. Me estuve guiando con unos ejemplos que vienen en el paquete, y con este schema XML.

Poniendo todo en la balanza, me quedo con Prebuild. Tengo lo de antes, más NAnt (con algunos pequeños sacrificios) y Visual Studio. Pueden probar esto bajándose el código de ZaspeSharp desde el repositorio Subversion (svn co http://zaspe-sharp.google…), y ejecutando el binario prebuild.exe (en GNU/Linux con Mono o en Windows) según lo indica el archivo README (no tengo idea si ese ingles está muy bien, pero se entiende).

El código modificado de Prebuild se encuentra aquí.

Algunos screenshots de ZaspeSharp en GNU/Linux y en Windows: