Dick Hollenbeck wrote: > One idea is to have the BOM generator generate a CSV file that the user > is to edit.
Heh, I still remember the howl of agony that went through the list the last time I proposed a (quite simple) text file as a means of user input (for ERC exceptions) ;-) [ Iterative BOM process. ] It seems that this would still duplicate manufacturer/distributor data across projects. The model Brian has described, with things arranged around a CPN, would avoid this. That's also what I know from industry, although with somewhat questionable MPR. I feel that things are starting to fall into place. In fact, even the two scenarios I described in my reply to Brian (1 "CPN and parameters a la carte" and 2 "user-provided CPN") would converge and complement each other, since they both use the same base information. >> This would also allow the BOM generator to be developed apart >> from the main KiCad codebase, which is probably a good thing in >> the long run. (And it might give me a chance to play, too :-) > > Yes, but this means duplicating all the schematic file loading code. Not at all. The existing BOM output would be largely sufficient for scenario 2. The only thing I can think of at the moment that would make things even better is if also the symbol name was available. That way, one could use it as a key for all the part/parametric tables. That would be very similar to the model Digi-Key's database uses: you first select a category (in our case, the symbol), then you further refine your selection by picking parameters from a table. What Digi-Key doesn't let you do is order by price when you've run out of ideas for further narrowing down your search. With symbols defining category, we'd have a coarser granularity than Digi-Key for "birdseed" (R, C, etc.), but much finer granularity than Digi-Key's catalog for ICs, which seems like an improvement to me. > I entered that *one time* into the *schematic* symbol property editor > for a user defined field called "Manufacturer" for *any one (1)* part > matching C1. So two components would "match" if they both have the same set of fields, and fields with the same name/position would have the same value ? "Choose alike" sounds like a convenient concept to me. In scenario 1, this could be modeled in the parametric search by showing the parts most similar to earlier queries, a bit like the "History list" you get in eeschema when placing new components. In general, "choose alike" should result more or less automatically once you have the full set of parameters and all that's left is to pick among equal parts. I'm sure there are exceptions where you're doing everything right and still a part you hate keeps on popping up, but then you'd have the CPN to override that too. > You thinking we should make Kicad into a spreadsheet? ... and one Excel to rule them all ;-) It looks more like a RDMBS type of scenario to me at the moment, luckily with nice enough properties that a few CSV files should do until someone needs record-wise exclusive access for joint editing. > What about passing stuff through > the clipboard, this is also easier than CSV files on the user, and > easier on us developers. Hmm, would that mean to use the primary clipboard as an IPC mechanism ? In this case, I wonder if users wouldn't complain if we override their copy and paste buffer all the time. If you're thinking of using another clipboard, how would users be able to access it (outside the KiCad world, where programs would know about it) ? I could see a place for the clipboard when picking things off the "menu" (scenario 1), so that the parametric search wouldn't have to live inside eeschema. The interaction would then be something like this: eeschema: asks for a parametric search eeschema -> psearch: symbol name, perhaps any fields already set psearch: user does some searching, finds, and accepts eeschema <- psearch: list of values, possibly including CPN Do we have an IPC mechanism that could be used to announce that we've put something into the clipboard, so that users don't have to first tell one side to send, then the other to receive ? - Werner _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
