← Back to team overview

kicad-developers team mailing list archive

Re: [PATCH] non-interactive plot mode for eeschema


Werner Almesberger wrote:
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.

We use a different curly brace style. The style is documented in a veiled form in the uncrustify.cfg file. You can run code through the uncrustify beautifier with our config file to get an idea. Many files have been run through there. So when something pops up that does not use that style, it is obvious, and distracting.

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.

If it is clean, and simple, it does not need to be comprehensive. To me it should be as simple as:



settings( stuff what you want here, like size, orientation, etc. );

s.Load( Filename )

s.Print( PrinterOutputDevice, printSettings )

delete s;


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 ?

The fact that a schematic is housed in a frame, does not mean that the frame should do the work on the schematic directly. Perhaps it does now, but this could be matter of moving the Load and Print functions into the schematic. I don't see it being that complicated.

If the schematic can exist outside the frame and it should be possible for such to occur, you should then be able to avoid having to instantiate any windows at all.

I think it can be done, even if it means writing a new main() and linking the program differently to a new main.c type file.

Or do you disagree with the idea of non-interactive use per se ?

No, but putting stuff like what you have in there causes folks to trip on it. It is like putting junk just inside the garage door. No way to get the car in.

Ideally, some of the these Kicad programs might be better split into a main and a shared object file combo. The shared object file would have the document model in it, namely the SCHEMATIC in our discussion. Then a person could link different mains to that document model, some of which would not need to have a gui at all. When an error occurs, these document models should throw an exception, not hose to a window. That way a caller far higher up the chain can catch the exception and decide to hose to a window or simply print an error.

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.

Well please give Kicad some credit for what it tries to achieve. You are coming in far after the design goals were established and changing them. Your point and needs were made long ago, I don't think this is fair to say here and now that it is a "great shortcoming". What you want is an enhancement, and one that is not unreasonable if Kicad was structured properly.


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:


The result is this:


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


Yahoo! Groups Links

Follow ups