Libgda: reports generation

Before releasing a 3.1.1 version of Libgda, I wanted to work a bit on Libgda’s report engine which is currently very broken (does not work at all and seems to have a difficult to use API). So I decided to reimplement one into a separate component, even though this will break the API.

After a few hours, the reports component has a generic engine which takes an XML input, and replaces the <gda_report_…> nodes with some actual content, each of these nodes being commands to perform or display some data. With only 5 of these commands, it’s possible to achieve some nice and complex results.

I have so far tested it with some DocBook and RML files. I can generate HTML from DocBook very easily, but PDF generation is more tricky since it uses FOP (which is not always packaged on distros), and it’s easy to generate PDF from RML files. Even though many features are still missing, it’s a good start…

Sample output:

  • PDF output using this RML template:

pdf.png

  • HTML and then PDF output using this DocBook template:

html.png pdf-docbook.png

The code is in SVN trunk, and the examples which generate these outputs are in the samples/Report directory.

‘Repair’ your F-Spot database with Libgda

Continuing to work around the idea of virtual connections and virtual tables in Libgda (which allow to run SQL commands on data coming from databases but also from data models) I have written a small tool to repair an F-Spot database.

The “repair” term is a bit awkard since the aim of the tool is to correct the path of some pictures in your F-Spot database after you have moved them to another directory. For example if I had some of my pictures in /my/pics/dir and moved those to /another/dir then I can run:
repair-path /another/dir
and the paths will be corrected for the files which have a unique file name in /another/dir.
The tool is far from being featurefull as it for example will look only for unique file names in resolution, but it’s just an example.

Internally a connection is opened to the F-Spot database (an SQLite file), a data model is created which lists the files in /another/dir and a virtual connection is created which imports the tables from the SQLite connection using the spot namespace, and shows the files table as the contents of the data model, as shown in the following diagram:

Connections setupSQL commands are then issued to the virtual connection to determine missing images and the possible corrections.

The code requires SVN trunk’s Libgda version and can be found in the http://svn.gnome.org/viewcvs/libgda/trunk/samples/F-Spot
directory. Make sure to read the README file for more information.

200 lines of C to make a file duplicates finder and remover with Libgda

To illustrate the usage of virtual connections in Libgda, I wrote a small program which is just about 200 lines of code and which can either:

  • show all the file duplicates in a directory (based on actual file contents comparison, not just MD5 hash)
  • show the file duplicates for a file
  • show and delete the duplicates for a file (though it should not be used in production machines as there are probably still some bugs).

All this is made using some SQL code on a list of files made into a data model.

I thought it would be slow but in the end it’s quite quick as it takes only 5s to search for duplicates in GLib’s 1000 (not compiled) source files and 9s for GTK+’s 3500 files (the duplicates seem to be images from the documentation, but also for example gdk/win32/gdkspawn-win32.c and gdk/quartz/gdkspawn-quartz.c).

The code requires SVN trunk’s Libgda version and can be found in the http://svn.gnome.org/viewcvs/libgda/trunk/samples/DirDataModel
directory. Make sure to read the README file for more information.

The next step is to make a small program to help repair an F-Spot database if the user has moved files around (as I should not have done).