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 _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
