kicad-developers team mailing list archive

[Dick Hollenbeck <dick@...>]

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:



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 )

delete s;

Done.


> 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.


Dick


> 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
>
>
> ------------------------------------
>
> Yahoo! Groups Links