On 7/29/2010 9:07 AM, Dick Hollenbeck wrote: > On 07/29/2010 01:25 AM, Lorenzo Marcantonio wrote: >> On Thu, 29 Jul 2010, Dick Hollenbeck wrote: >> >> >>> This is one thing that could be done to the BOM generator. I don't like >>> the current dialog window there at all, and am not too exciting about >>> fixing something for which I have no enthusiasm for. I am not sure it >>> is worth salvaging. A few lines of python code will do a better job and >>> give the user the ability to easily refine the output him/her-self. >>> >>> What do people think?
I like it. I think most of the devs on this list will like it. I am not so sure about the non-dev users. My guess is that everyone on this list could easily refine the output him/her-self. Does the general user have that ability? I've learned a long time ago to dismiss what I think is a great idea that other people will want because I have found that I am the minority when it comes to computer users. Maybe this is a question that should be asked on the Kicad users group as opposed to the developers group. You may get a less dev biased opinion there. >>> >> That most people on Windows (and some on Un*x too) don't have python >> installed (I had to install it to use bzr). Other than that is a good >> idea. >> >> Maybe just keep in a 'simple' report for the non-scripting-abled people >> (like the current 'sorted by reference, all fields') one) I think this is a far more reasonable solution for non-dev users who just want to click few check boxes and be done with it. >> > > It's actually pretty much garbage. I really would like to see it go > away before it gets expanded on by the next guy who is unhappy with the > output. Everyone has their own needs here. Nothing precludes the > sharing of scripts with others on the mailing list. Or if you want to > write a custom one and keep it for yourself, that is OK, or if you want > to use only the supplied scripts, this is ok too. We can ship 18 sample > scripts, and the user can pick which one gets chain executed. The current BOM dialog and code leave a lot to be desired (I know, I have the gift of understatement) but I don't think users will want to hunt down a script that formats a BOM the way they want it. Even if one of the default scripts was adequate, how would you convey to the user what output format the script generates? > > Up until seeing this BOM C++ code, I never knew a CSV file could or > would use a tab or a semicolon as a separator. I thought the C in CSV > meant comma. This is one of those areas where a needs analysis > discussion might have been helpful before writing all this code. I am > trying to do that now. > > >> And, since it's external anyway, just say 'an external postprocessor' (I >> would do it in perl, for example :P). > > You can have *your* perl, if this idea comes to fruition. I see you > licking your chops. > >> I think that the intermediate file >> would be something like the 'module report' in pcbnew, it can be a sexp, >> an xml file, yaml or even a csv file, I have no preference on this >> (well, I actually loathe xml :D). > > CSV is not an option for the intermediate file, since we are not dealing > with tables at this point. Each schematic part can have its own set of > fields/properties and those fields won't be unified or reconciled ( = > tabularized ) until we get over to the scripting environment. Therefore > we have to export the field/property *names* and values. > > > I woke up this morning leaning towards a comprehensive XML export as the > intermediate format, because just this week I used xsltproc to transform > an XML file to another format with ease. Xsltproc is easy to use, and > provides another option for us if we use XML as the intermediate file > format: > > > $ xsltproc stylesheet.xml schematic-parts-intermediate.xml > bom.csv > > > xsltproc is just another option, I think python is best for the 3 > samples though. > > We should not rule out XML. > >> Taking to the extreme a BOM reporter >> could actually traverse without much problems the whole .sch hierarchy >> :P:P:P >> >> OTOH the *current* bom lister is becoming... unwieldy; I'd like a trim >> to it, too. With your proposal would be more or less a scan like that >> done by the search function, just dumping away the object attribute. >> >> I vote for it. My reservations aside, I think this feature has lot of merit. Maybe it should be a separate action from the current BOM dialog instead of a replacement for it. Wayne >> > > So is one + one vote enough? Or should I go back to work, and leave > this for another month or year? > > > 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
