← Back to team overview

kicad-developers team mailing list archive

Re: Library work


On Mon, 23 Feb 2009, Manveru wrote:

For me it is obvious to have separate tree for library work. Well, it
is not enough in my opinion - we should have some web/wiki system, to
publish symbols for discrete elements (maybe others in future) on-line
for review, what is done and what not. Symbol and elements libraries
should be separate subproject.

Yes, definitely. I think git would be almost optimal for data strage and then just suitable bacends for web interface. Say automatic png rendering for non svg browsers etc. Wiki should imho be a backend for git as staying in sync and keeping version is very important.

I think here is a technical limitation of symbol editor currently
present in KiCad. SVG format is very nice (Inkscape is nice and
advanced open source editor for them), but it does not have
constraints for electrical/electronic symbols. As far as I remember
there are metadata possible, which would be used for marking pins, or
other characteristics of elements drawn in SVG format. Other idea is
to have separate named layers for different parts of the symbol

Other technical problem is how to move work from SVG into KiCad. I do
not think it is possible to support quite heavy format like SVG as
symbol container. I do not know how strong is wxWindows support for
SVG, and how heavy...

Yes, I think memory usage would get too large for native SVG support in schematics. But just for it's universal editor support should give it a very serious thought as an primary format. My first implementation idea was to make everything but pins in SVG. Pins woul be parsed on the symbol later on. For SVG pins, just put certain line style tag or something to point pin position and style. Layer support in SVG also makes these things easier. Also symbol conversion to native Kicad do not have to be rounding exact in other places but pins. Pins are just force fit to grid during conversion step.

What else bothers me, is hierarchy of current elements in the KiCad
library. I had an idea once to suggest new project which creates
hierarchy for elements and new way of handling them in not only KiCad.
I would like to have separation between discrete elements like diodes,
resistors, etc. which have standardized graphic symbol on schematics
and between microchips. Additionally we should have elements like
holes, which do not need symbol on schematic (or may need, as I saw
schematics where holes were grounded). Typically microprocessors and
programmable arrays are very specific to its manufacturer, while there
is many other standardized chips like 74xxx. There should be a method
allowing to assign elements to second or even third category in
hierarchy. This would make searching of elements much easier.

Classifications are somewhat messy, but also very difficult. See, one may prefer manufacturers on special purpose ICs and other function... Both are IMO needed in optimum setup, but optimum may never get ready for use... This is actually one step further from making symbols I guess ;)

I think your or others effort should start from preparing a document
about KiCad library style for all current and future participants.
This would be much help as when I made couple of elements to my
library, I do not know whether these conforms standard and it is worth
publication... and if it's worth, where to put it.

Maybe Igor could help here. I don't know jack about working on SF and it seems I don't have time to learn just now. Also 'release early and release often' applies here I think. It should not be offense if something to correct is found. Library style is a bit difficult as it includes opinions... so, it may be somewhat demanding. Something around lines of old elector symbols seem nice to me, but somewhat lighter lines are needed on times. Current resistor symbol is fine I think :)

At this point I just think up that symbol/module editor should offer a
function "Submit to review by community...", which publish work of
user on a web page where I could be voted and commented, before it
would be committed to the official library.

Separate git branches would allow this realized easily... Time to time just merge 'all good' stuff to official tree.

Wow, I typed so many words - please excuse me. It had to be short
message, but when I start typing my ideas become more and more clear
to me. That is all for now :-)

It's all good. Sometimes I tend to stuble in my own 'cleverness' later on, but that's just learning ;)


Follow ups