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

[Bill Gatliff <bgat@xxxxxxxxxxxxxxx>]

Stuart Brorson wrote:
>> 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.

Ok, I'll put you down as "not in favor of Dia".  :)

I fired up Dia for the first time in a long while just this morning, and
it's still the same tool as it was several years ago.  So I'm inclined
to agree with you.  It occurred to me just because it has a well-defined
scripting backend that the tool itself makes extensive use of.  That's all.

> 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.
>   

I know nothing of the internals of gschem.  But Dia appears to treat its
visual symbol objects as _objects_, and the scripting language works
with them at that level (similar to how Visio works, which I am very
familiar with).

I don't think that gschem needs any awareness of electronic
components--- in fact, I think that would be a Bad Idea.  Rather, it
might be easier to do some of what I'm thinking is necessary by allowing
gschem to understand drawings in the same way that Dia does: as a
network of interconnected symbols (a "net" is a form of symbol in my way
of thinking), each of which may have one or more attributes associated
with it that gschem merely has to provide to the scripting backend.

Gschem may in fact work this way, for all I know.

Maybe if things worked the way I describe, then backends could be
produced to deal with the circuit-specific knowledge--- matching symbols
with circuits provided by components, for example.

> However, there is a large installed base of scheme

Is there?  Could we get a show of hands as to who is doing a significant
quantity of scheme programming in their use of gEDA?  Stuff that might
get broken of gschem switched to another scripting language, I mean.


b.g.

-- 
Bill Gatliff
bgat@xxxxxxxxxxxxxxx



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