Hi all,
Rather than revising for my exams, I've been rewriting the component library
system. My new all-singing all-dancing code is now in a runnable state, and
the patches are attached. Once they are extracted, apply to CVS HEAD with:
cat /path/to/patches-libraries/*.patch | patch -Np1
General notes:
(1) Each patch has a comment block explaining what it does.
(2) 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.
(3) 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.
(4) 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.
(5) 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.
(5) For those wishing to import the patches into a version control system,
the first patch adds libgeda/src/s_textbuffer.c
(6) I'd like to get this into CVS before the next code sprint, so I'd very
much appreciate lots of testing and bugs found.
Known bugs/todos:
(1) The lists of sources/symbols should be sorted by name.
(2) A source type based on Guile callbacks would be good (not too
difficult, either, since CLibSource is an opaque data structure).
(3) It is possible for non-const pointers to CLibSource or CLibSymbol
structures to be obtained using the functions which return GLists.
(4) Categorisation of symbols in a more fine-grained manner than just by
which source they came from.
(5) Search algorithms are currently quite brute-force, and should be
optimised (lots of hashtables).
(6) It would be nice for command sources to have custom arguments used to
retrieve symbol data or lists of symbols. Currently the 'get'
and 'list' arguments are mandatory.
(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).
Diffstat (most of the added lines are in DOxygen comments):
gschem/src/g_hook.c | 38
gschem/src/i_callbacks.c | 21
gschem/src/o_complex.c | 40
gschem/src/o_copy.c | 5
gschem/src/o_misc.c | 49 -
gschem/src/o_net.c | 15
gschem/src/x_compselect.c | 169 +--
gschem/src/x_window.c | 1
libgeda/include/prototype.h | 67 +
libgeda/include/struct.h | 18
libgeda/src/Makefile.am | 2
libgeda/src/a_basic.c | 129 ++
libgeda/src/g_rc.c | 53 +
libgeda/src/g_register.c | 3
libgeda/src/o_attrib.c | 42
libgeda/src/o_complex_basic.c | 203 ++--
libgeda/src/o_embed.c | 43
libgeda/src/o_list.c | 3
libgeda/src/o_picture.c | 44 -
libgeda/src/o_text_basic.c | 23
libgeda/src/s_basic.c | 4
libgeda/src/s_clib.c | 959 ++++++++++++++++++----
libgeda/src/s_hierarchy.c | 8
libgeda/src/s_textbuffer.c | 218 +++++
libgeda/src/s_toplevel.c | 1
25 files changed, 1575 insertions(+), 583 deletions(-)
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.
Cheers,
Peter
--
Fisher Society http://tinyurl.com/o39w2
CU Small-Bore Club http://tinyurl.com/mwrc9
09f911029d74e35bd84156c5635688c0 peter-b.co.uk
Attachment:
patches-libraries.tar.bz2
Description: application/tbz
Attachment:
pgpUSPb1HUVEN.pgp
Description: PGP signature
_______________________________________________ geda-dev mailing list geda-dev@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev