kicad-developers team mailing list archive
Mailing list archive
Re: [PATCH] non-interactive plot mode for eeschema
Dick Hollenbeck <dick@...>
Sat, 16 May 2009 14:39:28 -0500
Thunderbird 184.108.40.206 (X11/20090318)
Werner Almesberger wrote:
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.
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
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:
SCHEMATIC* s = new SCHEMATIC()
PRINTSETTINGS settings = new PRINTSETTINGS();
settings( stuff what you want here, like size, orientation, etc. );
s.Load( Filename )
s.Print( PrinterOutputDevice, printSettings )
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
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
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
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.
Yahoo! Groups Links