On Tue, Jan 18, 2011 at 2:05 AM, Peter Clifton <[email protected]> wrote: > >> Connectivity is precisely the kind of thing that should not be in >> libgeda. > > I (and all other gEDA developers I've talked to) disagree.
That's interesting. Many of my issues with gschem and gnetlist are at some level related to low level of abstraction provided by libgeda. What people expect from EDA tools is not a "pretty drawing" (that's what they use PowerPoint for), they want these tools to assist them in the design and maintenance process, freeing them from remembering everything and perhaps catch some errrors. This assumes that the tool has some "knowledge" of the application it is used for. Sure, it is impossible to design a perfect tool (that would mean the designer is no longer needed), but more the tool knows, the better. This is the first time I hear that gEDA developers are even considering changes in this area (or was it simply because of closing down the geda-dev mailing list?). If that indeed is the case, I could do some work on the project without having a feeling of lost effort. The question is, how far would you like gEDA to go in this direction? IMHO this should go rather far (you know, others were doing it for decades). Libgeda (or, what I'd like to call it, the "database") should be _the_ way of accessing and interpreting the design data, perhaps even doing some IPC so that different program instances, each linking to libgeda are aware of each other. An open, documented backend (file format) is still valuable as a fallback option (for quick scripting jobs that do not need full knowledge of the design connectivity etc.). The latter option + open API is what distinguishes gEDA from commercial guys - they, in addition to all the engineering purposes, tend to use the database as a lock-in tool. Andrzej _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
