kicad-developers team mailing list archive
Mailing list archive
Re: BOM support
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
>> 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
> 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
> $ 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
>> 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.
> So is one + one vote enough? Or should I go back to work, and leave
> this for another month or year?
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp