kicad-developers team mailing list archive
Mailing list archive
Re: Reorganization and QC of kicad library
Thank you for your suggestion. I agree with all your points.
I'm going to create a blueprint when all of my draft is ready.
After reading the new library document, it seems that my work is narrower.
It is based on a user perspective (me) rather than a developer one.
I am going to define a set of guideline/rule for symbol, footprint and 3d
This guideline should contains drawing style, naming scheme, size and
position of drawing/text element of symbol/footprint/3d model.
Existing standard will be applied to the guideline. This should improve
look & feel, correctness and standard of schematic & pcb drawing.
I will use the new library definition in the guideline.
On Fri, Nov 4, 2011 at 10:11 PM, Dick Hollenbeck <dick@xxxxxxxxxxx> wrote:
> 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:
> 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
> 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:
> 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.
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp