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 <[email protected]> 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 : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp >
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
