[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: gEDA-user: Soft and Hard symbols

On Tue, Jan 18, 2011 at 2:05 AM, Peter Clifton <pcjc2@xxxxxxxxx> 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.


geda-user mailing list