kicad-developers team mailing list archive
Mailing list archive
Re: Re: Libraries - files and components naming policy
Tue, 13 Oct 2009 09:03:13 +0200
2009/10/12 Vesa Solonen <vsolonen@...>
> I'm still pushing the hybrid way. Special purpose stuff as heavy symbols.
> Most of the connectors would work fine on light system too when they just
> use pin number. There are quite a lot of discretes in use too that would
> make a helluva library with all the variants.
The project should avoid any shortcuts leading to a mess in the
future. So, hybrid way is a must IMVHO.
I think the more number of common symbols the merrier. It helps
keeping consistency in the style of symbols. There is really a lot of
elements having common symbols on schematics: all discrete elements,
amplifiers, converters (at least they should have common symbol for
typical usage), elementary digital logic, relays, switches,
I even think that classes of symbols with inheritance would be nice
feature to have, but I can imagine the level of complexity needed to
implement such behaviour. The RS232<->TTL converter for example would
have common symbol for typical signals and specific part would inherit
it adding pins very specific to single chip.
About documentation. Pure LaTeX is too problematic for a team to
follow as it needs keeping a "coding style" of the document. It is
then easy to keep on repository and easy to merge. It you would not
choose OpenOffice.org, I suggest LyX. It does not have document merge
functionality (this feature is still looking for sponsors), but I
successfully merged simple changes directly in its text format. It
generates nice looking documents through the LaTeX. And hardly forces
style of document. I will try to find some time this week to present
an example of LyX template and PDF output for KiCad's documentation.