kicad-developers team mailing list archive

[Fat-Zer <fatzer2@xxxxxxxxx>]

Sorry about accidental send previous message.

2015-01-14 18:53 GMT+03:00 Andy Peters <devel@xxxxxxxxx>:

> > 2. Different images of the same schematic component.
> > There are already such variants for some common components like CP, also
> there are "small" variants for some components.
>
> Who cares about a symbol variant? Pick the one you prefer and use it.
>
yep, but for user can be able to easily chose it, kicad library should
provide them out of the box... And I propouse a way to store them in
library more straightforward IMO.


> > In both such cases we can keep information about the component in single
> symbol.
> > Also as a bonus we can easily support both IEC and US symbols and use it
> in some other cases.
>
> Why? I think that a lot of advanced users will choose one symbol type and
> leave it at that, and not go the route of switching between one symbol
> variant and another.
>
yep, but it's a suggestion in case of open hardware environment. It may be
usefull in case you are reusing somebody's else workarounds. but it's not a
first goal, just a suggestion for a bit more distant future...
By the word, I'm not really experienced in that and may be totally wrong.

>
> > 3. To store pin number of component in additional field.
> > Now cvpcb guesses pin number according to the pins displayed on the
> schematics. Which is wrong if some pins are not connected/not present in
> the schematics at all.
>
> That problem is solved by not using CvPCB at all, and doing as I suggest
> above.
>
Yep... From your words the getting rid of cvpcb sounds great... if you can
handle such a work (taking in mind that schematic and footprint library are
nearly two different pices of data for now) I, personally, will appreciate
it... and I believe it will be appreciated by a lot of other members of the
community... I won't have enough time and (honestly speaking) skills to do
that on my own...

>
> > It would be great to store an overall pin number of component too (as an
> option).
>
> For what benefit?
>
Just an accidental retype of the previous one... don't take it into the
account...

>
> ---------------
>
> OK, I realize that the point is to somehow improve library sharing. I
> think that's an excellent goal. But I also think that at some point, it
> breaks down. Unless all shared libraries adhere to the same standards,
> inevitably you have problems. And I know you can't please everyone, so
> perhaps the correct way to go is to support the hobbyists who don't want to
> create a complex library system for a small design, and the
> advanced/professional users will build company/vetted libraries.
>
Yes, that is... IMO the main audience of the kicad will be hobiest and some
more experienced people from openhardware world for the nearest future. So
the idea to support there needs doesn't sounds so crazy, isn't it? ))
BTW: there are already some general rules:
https://github.com/KiCad/kicad-library/blob/master/KiCad_Library_Convention.txt
And I suppose they will be updated with the new format features.


PS: I'm looking forward to here a bit more feedback from library
maintainers... I hope they are following the list, isn't it?
PPS: As I understood from the neighboring thread the format change with
forward compatibility is not the big deal?