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:
- 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.
- 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.
- 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.
- 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:
- The lists of sources/symbols should be sorted by name.
- 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.
- 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.
- It would be great to be able to categorize symbols in a more
fine-grained manner than just by which source they came from.
- Searching for symbols is still quite a brute-force process, and
needs to be optimised (lots of hashtables).
- 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.
- 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.
- 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.
