So to take this adding too much complexity argument to street and shoot it.
if we have plugins, this is simplified..... if a plugin can register a hook on a component place, this can call an interface to the Data On Materials (DOM) database. <annoyed> For those who only think of mySQL when programmers say database... database |ˈdatəˌbās; ˈdā-| noun a structured set of data held in a computer, esp. one that is accessible in various ways. ^^^^^^^^look flat files in directories are a database..... </annoyed> Inside of this plugin it takes the light symbol that gEDA provide and applies its magic. pow the symbol has the info that is required for your process, from your DOM database Wouldn't a digikey/mouser plugin rock? we should work with them to get an interface working..... On Jan 21, 2009, at 9:06 AM, John Doty wrote: >> The extra database contains (or could contain) all this information. > > Millions of entries. Impractical for us to maintain. gEDA does NOT maintain user component databases, there no way we would know what part number thy would use! now for an example that dosen't require PCB put generic symbols for TSMC's standard cells then a plugin can map them to the process ( silicon ) that you are using. now for post gschem..... if this plugin could be used as a filter for gnetlist, the parts go through gnetlist, each one gets filtered by the plugin, if info is missing something happens; you die and fix it in gschem or you could go interactive. as for PCB and the DOM database, it might be cool if it could pull a footprint from one... call a program and it spits out a footprint to sdtout. pcb then incorporates it into the pcb file. have a program that grabs it from JLC's page. :-) Hardkrash _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user