kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

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     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>