← Back to team overview

kicad-developers team mailing list archive

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


Within a body of code, it is important to be consistent. If you mix styles within a body of code, it looks like crap and eventually becomes totally chaotic.

Sure. Anything else would be madness. I just wish the style was a
little closer to the things I see every day ...

Then spend more time looking at Kicad code.

What I mean are things like this:
It's interesting reading, if only for the rationales. (Okay, some
simply say "K&R" :)

No thanks. Looking at linux source code makes me dizzy.

This is a C++ package, and we are entitled to like what we prefer. It is like arguing about colors.

I have written a lot of Java code and prefer that style over K&R, thank you very much. There is always a tendency on the part of new comers to try and persuade the project to change styles. After awhile you can get used to it.

We have too much time invested in the current style, thank you very much. But if you really want to continue, I can tell you why blue is not only my favorite color, but the best color.

I think Kicad needs to consider implementing a plugin system, similar to what is in Gnucap.

By the way, there's an interesting "new" approach in the CAD world.
There are various Open Source CAD systems (FreeCAD, HeeksCAD, Salome)
that are based on the OpenCASCADE libraries, add a bit of their own C++ for the GUI, and then use Python for scripting and to tie things together.

Document model on the bottom, gui or scripting on top. Sounds like my last posting without the OpenCASCADE attribute.

OpenCASCADE is a separate discussion, one that I really don't have time to enter into right now.

The key idea that should not be lost here is: document model on the bottom, gui or scripting on top. On that we can agree, and think this probably goes for anybody on this list. It will just take some time to evolve in that direction. I just did not want your kludge in the way while we evolve. Maybe a separate main() function or file will work best for you in the interim.

i.e. is is possible for you to link your own executable, with modules that you need tied to your own main function? If you code could be encapsuated in a single file, then putting that *.cpp file into project would not be disagreeable to me, even if it meant that you were the only one using it. There are non "ALL" targets possible in the CMAKE scripts. I have one in there for testing the specctra parsing and formatting. You have to ask for it to be built, otherwise it is not build.


Follow ups