New component library for gEDA

Rather than revising for my exams, I've been rewriting the gEDA component library system. The motivation was to provide a way to use the output of arbitrary commands as symbols in your schematic, and to have a way for code in gEDA applications to find and use schematic symbols without caring about where they're coming from.

My new all-singing all-dancing code is now in a runnable state, and I've put it on my public git repository in the "libraries" tree (breaking my "master" tree in the process, but hey). You can get it using the command:

cg-clone git://repo.or.cz/geda-gaf/peter-b.git

(Update: If you don't use git, you can get a magic patch between CVS and my libraries tree.)

I'm hoping to get the changes into CVS before the next code sprint (which has yet to be scheduled). For people wishing to try them out before then, it is important to note:

1. These patches touch a large amount of libgeda, and I have not tested whether or not they break anything other than gschem. gEDA with these patches applied should be considered dangerous; do not use it on production data. If it steals your car and runs over your dog, don't say I didn't warn you.
2. From a users point of view, gschem should operate exactly the same as without these patches applied. Please let me know of any changes/regressions.
3. These patches change the embedding mechanism. Embedding is now indicated by a single boolean flag (OBJECT.complex_embedded). However, the existing functions for (un)embedding and checking status have been retained.
4. There are extensive DOxgyen comments explaining the operation of the system in libgeda/src/s_clib.c. If they are insufficiently illuminating, please tell me what needs expanding on.

There are a number of bugs and things that still need to be done:

1. The lists of sources/symbols should be sorted by name.
2. A source type based on Guile callbacks would be good, so that users could define their own symbol-generating functions without needing to write extra external programs. It also wouldn't be too difficult to do.
3. Although I tried hard to protect the data structures containing the component source and symbol data from damage by making pointers to them "const" wherever possible, it is still possible for non-const pointers to the structures to be obtained using the functions which return GLists.
4. It would be great to be able to categorize symbols in a more fine-grained manner than just by which source they came from.
5. Searching for symbols is still quite a brute-force process, and needs to be optimised (lots of hashtables).
6. At the moment, component library commands are required to implement certain arguments ("get" and "list"). It would be nice for command sources to have custom arguments used to retrieve symbol data or lists of symbols.
7. It would be nice not to have to load a list of every single symbol available at startup. If symbols were being obtained from e.g. a database server, it would slow down gschem start significantly. This would fundamental changes to the way the component selector dialog works (a custom GtkTreeModel would be required) but other than that there are no major API obstacles.
8. Reviewing and descending hierarchy doesn't work for symbols without a filename (i.e. not from a directory-based library).

Send me any comments, complaints, suggestions, bug/crash reports, patches etc. I don't guarantee to do anything with them anytime soon, because if I don't do some studying now I'll be in big big trouble.