New library system now in CVS

After the SEUL server move was successfully completed, Ales released a new snapshot of gaf. With that out of the way I was given the all clear to merge my component library work.

I've therefore nuked the "libraries" branch from my public git repository, as it was no longer relevant.

There are a number of things I want to get sorted out before the next release (which is likely to be soon after the next code sprint on 9th June):

1. Rationalise the Scheme files in libgeda and geda-symbols. At the moment, the core rc file for gEDA is installed by the symbol package, and has loads of configure substitions in it. My plan is to:
   • Move all configure substitutions into a single file, config.scm, which would be installed with libgeda;
   • Provide some utility functions for common tasks like building paths from components;
   • Move system-gafrc from geda-symbols to libgeda, and split out the default component library & font setup code into geda-symbols.scm and geda-fonts.scm, which would be installed with geda-symbols.
   Other improvements to the Scheme files could be carried out later, but this would lay the ground-work.
2. While on the subject of Scheme, gEDA currently uses a lot of Guile functions & macros which are marked as deprecated in the current stable branch of Guile, 1.8.x. Since Ales has given the all-clear to move gaf to Guile 1.8, there are number of housekeeping tasks to do:
   • Update gaf configure scripts to check for presence of Guile 1.8 or later. Although currently the scripts check for the presence of certain functions, this is really difficult for developers, because it's something of a moving target, and it's hard to keep the configure scripts up-to-date with all of the functions people have used. It seems a lot more sensible to deal with it the same way as the GTK+ dependency has been dealt with: specify a particular version of Guile to support, and then make sure people do not use functions which require a newer version. Since Guile is very stable, this doesn't seem unreasonable.
   • Flush out all uses of deprecated interfaces, and generally make sure that we are using Guile the Right Way.
   A longer-term aim would be to use "guile-snarf" to generate code for registering Guile procedures made available by libgeda & gschem's C code. This would reduce the number of places where code would have to be changed when adding, removing or modifying a Guile procedure, and would hopefully make life easier for people new to the way libgeda & gschem work with libguile.
3. Replace the C code which currently implements the directory and command component library backends with equivalent Scheme code. This would make the component library code much simpler, and would have the added advantage of providing examples of how to implement new component library backends. This would very much require both a full upgrade to Guile 1.8.x, as well as the aforementioned reorganization of Scheme files.
4. Optimisation of look-ups. A simple optimisation would be to cache the results of s_clib_glob(), probably in a hashtable.

I'm intending to leave the next big killer feature, component categorization, until the release after next.

There are two big things which I'd like to be fixed before the next release that I don't think I'll have time to do:

1. Fix the preview widget to work properly with the new component back-ends. Currently, it needs to have a pathname in order to load the symbol for display, but it should be able to use the o_read_buffer() function I recently added to libgeda.
2. Make gschem be able to open schematic or symbol files not associated with a file (probably read-only). This would be much harder, but is more-or-less required for using gschem as the graphical front-end of a design database system (a future idea).

These are a couple of jobs which follow on from each other quite intuitively, and would make a big difference to my work. If no-one steps forward to do them, I'll probably leave them for the release after next.

Anyway, none of the aforementioned will happen before my exams, which finish on the 8th June, so I guess I'll have an awful lot of coding to get done between the code sprint and the next release!