kicad-developers team mailing list archive
Mailing list archive
Re: [PATCH] non-interactive plot mode for eeschema
Dick Hollenbeck <dick@...>
Sat, 16 May 2009 16:22:26 -0500
Thunderbird 126.96.36.199 (X11/20090318)
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
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.