On 04/09/2012 02:55 PM, Miguel Angel Ajo Pelayo wrote: > Now that may be we're still in time (well in fact, now I think that could be > added > lately without big impact..) > > What do you think about adding a UUID (I see now that you used 'LPID' > for SWEET) > to the PCB files, and also a revision number (that goes incrementally on > every modified > save). > > Also adding LPID to module/footprints would be great, think of the > concept for one > moment: > > > You could be able to keep your brd files in a database (also > distributed), and > check if your board version is the latest available, even ask for upgrade > from kicad. > > Also, with LPID + rev number in the modules/footprints, you could ask > KiCad to > interactively update your footprints from the > ones you have in the database. For example, somebody in your company could > have updated > certain footprint to enhance manufacturability or fix a silly orientation > bug... etc. > > I see a world of opportunities just adding: > > * LPID (or UUID) > * File Revision Number (automatical/autoincremental) > > And also keeping inside the .brd file: LPID + Rev Number of every > module. > > > I really love this idea, and I see that you already thought of it for > sch / lib parts.
Welcome to a 4 year old conversation. Your conceptual grasp is large. But the conversation is old. I thought about a UUID, but I invested money in an LPID. Does that answer your first question adequately? To summarize my feelings: a) what we have in SWEET is revolutionary, since we bring in inheritance, distributed LIBs, and versioning. Please watch for bullshit patents popping up on it to help me out. b) the opportunity and needs in PCBNEW are comparable or greater than in EESCHEMA, I have tended to think of the task as "bigger than EESCHEMA". This is a reason why I started with EESCHEMA, because I was certain that we'd learn things there that would be helpful when PCBNEW was re-worked. I have no interest in deviating from this original strategy because of that single reason. c) Once you add a logical library name, you can then abstract its implementation and location. d) Just last week, Jean-Pierre, Wayne and I exchanged emails on bringing in a logical library name into the *.kicad_brd to better identify the origin of a footprint within a board. I think there is support for just this little bit for now. The prior sentence is the most important one in this email, please read it again. Certainly doing more would require more brain cycles than are available at this time, and can always be done down the road in PCBNEW. I was hoping to abstract the library access methodology in the PLUGIN API, without going to the extent that I am in SWEET. For s-expression libraries, we are currently thinking of simply having a directory of s-expression (module) files, rather than a file of footprints. So a footprint library is merely a directory. This is a scouting report, it does not preclude conquering the world at some future point. But please realize that my commitment never even extended to even completing SWEET myself, let alone anything to do with PCBNEW. Said differently, my SWEET design needs implementors beyond myself to complete. SWEET does not apply and cannot apply directly to PCBNEW, although much that is learned there could eventually be used in PCNEW. The only reason we are cramming in the new file format now was the avalanche of the nanometers entering PCBNEW, did not want to disrupt user's lives inconsiderately with multiple file format changes. In summary, we are left dreaming and imagining, but get to each a little popcorn while we are doing it. My commitments are pretty well documented, and trying to commit resources that I do not have control over is foolish. In lose terms, given *current resources* this is what I see: PCBNEW minimally ---> EESCHEMA radically ---> PCBNEW better much later There are many things where we need help: nanometers: UI, DRC, dialogs, zoom, grid, status display of perhaps increasing drill down resolution as we zoom in. specctra export, gerber testing, etc. EAGLE PLUGIN: SWEET HTTP_LIB_SOURCE, which is likely to be a hell of a lot of fun. Dick _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
