kicad-developers team mailing list archive

["Mateusz" <komorkiewicz@...>]

I believe we should start to create some paper based on this discussion (naming policy is almost set, drawing guidelines also) it would be great to have it in pdf format with some images!

For me the idea of introducing a new file type is wrong because:

- common graphic symbol is good for small devices, not at all for ICs( mostlibraries are ICs or connectors libraries)

- another level of abstraction would make KiCAD harder to use (think about how many files the user will have to take care about)

- in matter of time, it is faster to copy and rename existing module pads than to create new Library Component (for 3-6 pad devices).

This is why I also don't support dynamic libraries. Scripts are great, but why not to build a great lib,mod generator and allow users to use it!

I was also thinking of dynamic styles and to tell the truth I don't know why it is so important for you. I agree that scaling a component on the sheetwould be great, but is the custom image of components really so important?

I believe it would be easier to use the existing line width parameter (now almost always set to zero) and allowing user to define the scaling parameters for device, and custom scaling parameter for each line width (let say 0.01 -> line type 1, 0.02 -> line type 2).

I think we should focus on most important things first otherwise we will have great ideas without implementation withing next two years. For me the most important thing now is the mess in KiCAD core libraries.

--- In kicad-devel@xxxxxxxxxxxxxxx, Vesa Solonen <vsolonen@...> wrote:
>
> On Thu, 8 Oct 2009, Brian Sidebotham wrote:
> 
> > Then an electrical symbol can be based on a graphical representation,
> > a module definition and all the other user fields that we have now and
> > the pin numbering information.
> > 
> > So that would give you:
> > 
> > * Common Graphics Symbols
> > * Schematic Symbols
> > * PCB Modules
> 
> After thinking for a while it seems we both had something similar in mind. 
> I'll take an example of 7805 TO-220 in the following.
> 
> ** Schematic symbol
> - Name: Three-terminal-regulator, positive
> - Pins: Vi, GND, Vo (exports these for library)
> - Binds to Three-terminal-regulator library
> - Looks something like current 7805
> - Drawing specified in line classes without absolute line widths.
> 
> ** Library component
> - Name: Three-terminal-regulator, positive + specifics (LM7805T)
> - Imports pin data from the symbol
> - Imports package and + specific component from Cvpcb or Schematic fields
> - Contains version specific pin mapping matrices to standard package pad
> numbering.
> - Contains documentation helpers
> - Exports pad mapping, bom data and what not (Vi=1, GND=2, Vo=3, 
> Tab=GND=4])
> 
> ** PCB physical component
> - Standard name, pad numbering and shape
> - 3D optional
> - Exceptions for non-standard stuff
> 
> That way only component libray needs a few lines addition if one likes to 
> add say, Micrel MIC5201-5 to it. If there is no standard symbol, package 
> or anything, then do it heavy way as an exception. Feel free to add 
> anything I forgot.
> 
> Are we set on naming? Actually it may make sense to postpone that too, 
> as it seems there is going to be a whole lot of infrastructural changes 
> that may make it somewhat unneeded in the end. I'm happy with current 
> proposals though.
> 
> -Vesa
>