Re: gEDA-user: How to deal with single/dual parts?

[Stuart Brorson <sdb@xxxxxxxxxx>]

> Would it make any sense to attempt to use Dia as an alternative gschem?

Sorry to come out of hibernation just to rant.

I've used dia many times over the years.  It stinks to high heaven.  It's 
user interface is clunky, its rendering is horrible, and its text
handling is a disaster.  Its been frozen at version 0.99 for years
because it remains stuck at a pitiful state of development.

Oh, and did I mention that it's hard to use?

Gschem is light years ahead of dia.  Gschem has been under development
for over 10 years and is very easy to use, IMO, once you learn the
keystrokes.  The recent complaints I have seen on this list about
gschem seem to stem from the fact that it is simply a drawing program
without knoweldge of electronic concepts like "net", "component" and
so on.  That is, gschem's basic datastructures are things like "lines",
"circles", "text", and so on.  In the current architecture, it's up to
gnetlist to read the graphical rendition of the circuit, add in the
circuit knowledge, and create a netlist.

If the desire is to endow gschem with knowdge of circuit concepts,
then ISTM that the best way to do it is to add those concepts to
gschem itself, preferably through hooks to scheme.  Don't derail the
project by adopting dia or any other drawing platform.

BTW:  As long as I'm ranting, let me observe that a good thing to fix
before making gschem more flexible is to replace guile with tiny
scheme, or some other built-in scheme interpreter.  The reason is that
the guile dependency is a major source of bugs for gEDA since the
guile people are more-or-less hostile to their downstream users.  They
change the API whenever they want and their dependency tree is
bloated with cruft of peripheral use.  In my perfect world, gEDA's
developers would first get rid of guile, and install some other scheme
interpreter directly into libgeda (i.e. don't link to it).  Then, the
code necessary to handle the circuit concepts would be written up in
scheme, and the hooks to invoke the scheme stuff would be written up
in the usual C.  For speed, some of the more basic structures and
operations might also be coded in C -- this is an implementation
detail.

As an alternative to scheme, some would prefer to see TCL.  I have no
problem with that, as long as the interpreter is built-in.  However,
there is a large installed base of scheme, so it's likely we're stuck
with it.

Thanks for listening,

Stuart


_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user