← Back to team overview

kicad-developers team mailing list archive

Re: BOM support


On Thu, 5 Aug 2010, Dick Hollenbeck wrote:

Good question!  We were told recently that there are a number of
projects "out there" that might come under an umbrella of contrib.  I
wonder if we opened that gate how many would arrive carrying their own
language and tool requirements?  Own programming styles, own tool-sets,
own user interface standards?

No problem for a contrib... if someone wants a, dunno, matlab interface,
of course it can impose its own devel requirement. But for a core
component (like the BOM processor) IMO we should limit to something very
available (and I think python *is* very available, but without some
strange UI component).

*** I think we share the same concern, if we open the gates.  I don't
want to even look at C code written by somebody that thinks the linux
kernel source looks good, complete with tabs.  I would not want to have
my grep tools even go down in there while searching for a function name.

I find kernel sources actually very readable... and cscope grep them
pretty well too :D OTOH my main business is programming MCU and DSP so
it's mostly a (little) C and assembler affair.

Had we had a tool/utility language standard in place, then perhaps
things like Oyvind's part library would have been done in that up front,
rather than in perl.  The speculation is that with an published open
door policy, then folks could work in a particular scripting language
under the advance understanding that the tool has a place to live later,
and not die on the vine.

I could never script in python (well, I *could* but I absolutely hate
the indentation stuff without braces to % in vi). My part libraries are
built with zsh script, anyway... but, we're talking about contribs.
I someone wish to use it, it need to install the relevant requirements.

But for the core parts I'd stick to a restricted set of tools. I would
hope for something like POSIX but for UIs :D

made, if only because of the platform independence of the JVM and all
the languages that run on top of it.

Frankly, I cannot see why cvpcb could not be written entirely in PyQt4,
and be a central ram resident real-time interface between eeschema and

I my world cvpcb simply wouldn't exist and only be a dialog box in
eeschema (right click on the part, choose package). It's the only
fricking thing it does!

pcbnew, like we talked about for D-BUS.  Also, I am not sure why a
person needs both kicad AND cvpcb programs.  Seems that one could do the

I think it is something like an 'industry standard', both orcad and
eagle have a 'launcher/project manager'. Also it somewhat sets the
environment so that eeschema/pcbnew can pick the right files (at least
I think... if I do an eeschema file.sch it never find the libraries...)

Lorenzo Marcantonio
Logos Srl

Follow ups