kicad-developers team mailing list archive

[Phinitnan Chanasabaeng <phinitnan_c@xxxxxxxx>]

Hello Dick,

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
model creation.
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.

Tony


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:
>
> 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
>
>
>
> _______________________________________________
> 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
>