kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 11/03/2011 10:52 PM, Phinitnan Chanasabaeng wrote:
> Hello,
>
> hauptmech, thank you for the doc, it is very useful. I only have ipc-7251,7351 here.
>  I'll read through it and see what I can apply to the library.
> I also plan to develop such calculator or at least a better footprint viewer for kicad.
> This viewer will be very useful for Cvpcb & Pcbnew.
>
> fabrizio, I would like to create a new library set for kicad. What I'm doing now is
> defining standard, guideline, etc (drawing style, naming scheme, etc)  for the library.
> This works is due to, in fact, I (almost) never use current kicad library which is,
> IMHO, lack of consistency, standard, not quite beautiful.
> I use my own set of library (and I think many do). I think we should share the library
> so we can improve library usability & variety.
> I thought about improving the current library. But it can break any existed design.
> Therefore starting a new library is better choice for me.
>
> Simon, good idea. With user submitted libs, kicad library dev (could be
> kicad-library-committer) can review if the library meet the defined standard and merge
> to the main branch. One problem that came to my mind, where will the submitted libs store?
>
> Tony


Some suggestions:


1) Perhaps move this discussion to a launchpad blueprint, just to capture the thread for
historical continuity.  (I believe this is the 3rd or 4th time this topic has received
more than 6 postings.  For example, to begin without knowledge of or reference to Oyvind's
footprint generating perl scripts shows that continuity has been lost.)
Having a blueprint for this topic may help with this, and bring continuity.  At least it
puts a wrapper around all the email postings?   Ideally, mine would be the last posting
that is not on a blueprint.


2) Define a small set of terms that you can use in this discussion.  For me, "library",
without a definition, is ambiguous and therefore inadequate, since it does not incorporate
"footprint" and leads to confusion about whether you are talking about EESCHEMA or PCBNEW.


3) It is helpful to know what work is under way.  Read this document: 
http://bazaar.launchpad.net/~kicad-testing-committers/kicad/testing/view/head:/new/design.h
This design brings a number of new concepts to schematic design:

a) "schematic part retrieval" now can use a world wide picking list due to the LPID and
library table concepts.

b) "schematic part retrieval" is done through a software abstraction layer, i.e. retrieval
API.

c) the "parts list" is your local customization playground or staging area.


It does not address footprint retrieval or anything relating to PCBNEW.  I believed and
still do that much would be learned by focusing on EESCHEMA, which is an easier problem
space, before tackling PCBNEW.


4) Define a single document which lists your objectives, i.e. what problems you are trying
to solve.  Then sort this list by priority.  This document is initially more important
than the "spec or the standard", since it will drive the latter.


5) Spending a lot of time describing what a schematic symbol should look like, could be
done either using the current EESCHEMA as a premise, or it might be done using an
assumption of a new EESCHEMA which supports SWEET and uses terminology and paradigms that
build on what is coming forth in SWEET.  To do the latter means you have to understand
inheritance, the parts_list, and SWEET itself.  The SWEET spec is here:


 
http://bazaar.launchpad.net/~kicad-testing-committers/kicad/testing/view/head:/new/sweet_spec_for_schematic_parts_EN.fodt


And hopes to be loadable into openoffice, although not all versions are yet supporting the
fodt file format.

Regarding 5) a decision needs to be made how you want to spend your time:  current or
future EESCHEMA tool.   And likewise, current or future PCBNEW tool.

------------------------------------------------------



Best wishes, and look forward to reading more on a blueprint.


Dick