I have been keeping silent about this. But I am in the process of a major rewrite of the netlist program. In this process, I folded libgeda into my code base with the intent of eventually extracting it again in some form or another.
My work has 1) rewritten the struct.h data structures. 2) rewritten large amounts of the code for supporting these data structures. Including attempts to keep the api consistent from object structure to object structure. 3) rewritten the netlist algorythms 4) made heavy use of GList and GString data structures from gtk This new netlister, currently supports hierarchical buses. It is capable of exporting net lists for pcb and almost for PADS-PCB from mentor graphics. It also supports a BOM generator. There are numerous bugs that still must be fixed (embeded symbols arn't supported and must be). But I would request that those interested in a clean up of the data structures and API to please take a look. Thanks, Steve Meier Snapshot Code is available at: www.alchemyresearch.com/mra_netlist_20070228.zip Peter TB Brett wrote: > Hi folks, > > Bit of an update on this. Ales & Peter C. rightly pointed out that any > changes to libgeda need to be done by refactoring rather than rewriting. I'm > therefore proposing the following as initial steps: > > 1. Mark application-specific API elements in libgeda as deprecated, and phase > out their use. gschem, gnetlist & gattrib are the worst offenders here, > particularly w.r.t. the w_current structure. > > 2. Rename all public API elements to use the prefix "geda_" (or "GEDA_" for > constants & macros). This would be a good time to implement a clearer > naming convention for functions & structures too (glib/gtk's might be a > good model). > > 3. Create "private" header files in libgeda's src/ directory (these will > *not* be installed to /usr/include). Identify declarations & definitions > that should only be used internally and remove them from the public > headers. > > The first of these three steps will be the most difficult, but please do make > it a priority. At some point I will try and make detailed list of what needs > moving out. > > A suggested first step for application maintainers is to introduce an > application context structure that holds the things like dialog box pointers > that are currently stuffed into w_current. > > Please now tell me how this could be done better! > > Thanks, > > Peter :) > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > geda-dev mailing list > [email protected] > http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev > _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
