kicad-developers team mailing list archive

[Werner Almesberger <werner@...>]

Dick Hollenbeck wrote:
> The C++ style is wrong.

Hmm, I wouldn't be surprised by that :-( My background is C, not C++.
In fact, KiCad is the only C++ project to which I try to contribute,
however infrequently and lightly.

I also have to admit that I'm having a hard time with the coding style
used in KiCad. It seems to be almost diametrally opposed to the style
used, say, in the Linux kernel. (This isn't just a C vs. C++ thing.
E.g., also Stroustrup, while having some inconsistencies, still stays
fairly close to K&R style.) So whenever I try to write any code for
KiCad, I always have the feeling that I'm doing something terribly
wrong, be it either departing from the coding style or not writing
clean code.

> The idea is incomplete.

Do you mean because it fails if there are dialogs or because you'd
want to develop this into a more comprehensive set of non-interactive
controls ? I'd really love to have the latter.

One problem I see with implementing this cleanly is that the
abstractions don't really seem to support it. E.g., why would a
function that generates a Postscript file from a given set of internal
data structures have to be attached to a "frame" that's to a large
part a GUI structure to support GUI elements ?

Or do you disagree with the idea of non-interactive use per se ?
Coming from the Unix world, where workflows are often automated by
combining small tools, I find KiCad's inability to perform routine
tasks without manual intervention a great shortcoming. Particularly
printing operations have to be done frequently, are relatively
complex, and mistakes may be costly.

> Others may disagree. But I see now reason to be bashful about my 
> opinion on this one.

Well, I hoped that I had struck a reasonable compromise between
intrusiveness of the change and general neatness, but if you say that
isn't so, I'll accept that verdict.

So how do you propose to proceed with this ? Perhaps I should explain
what I'm using it for: we're starting a project to reimplement the
design of the Openmoko FreeRunner (GTA02) with KiCad. The original
was done with PADS.

This is supposed to be a collaborative effort that is both open and
distributed. One important aspect of this is to make it easy to review
the ongoing work. To that end, I semi-automatically generate
Postscript files of the schematics. The script that does this is here:

http://svn.openmoko.org/trunk/gta02-core/expanded/Makefile

The result is this:

http://people.openmoko.org/werner/gta02-core/gta02-core-expanded-all.ps.gz

We're currently in the process of building the library of circuit
symbols, that's why the components aren't connected to each other and
why the pin type is printed next to each pin (again, this is done by
a script).

Without eeschema --plot, this now automated process would have to be
broken into two parts, with someone manually clicking through the
invocation of eeschema. If you do this several times a day, it gets a
bit interruptive and it's only a question of time when you'll start
making mistakes.

I believe this functionality to be useful also outside of this
specific project (and I would want an equivalent in pcbnew as well),
that's why I think it would be sad if we had to keep our changes in
a private fork.

- Werner