kicad-developers team mailing list archive

[Vesa Solonen <vsolonen@...>]

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
> itself.
>
> 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 ;)

-Vesa