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):
- 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.
- 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.
- 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.
- 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:
- 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.
- 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!
