kicad-developers team mailing list archive

[Dick Hollenbeck <dick@...>]

> > 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:
> http://lxr.linux.no/source/Documentation/CodingStyle
> 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.


Dick