kicad-developers team mailing list archive

[Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx>]

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