kicad-developers team mailing list archive

[Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx>]

On Sat, Feb 15, 2014 at 10:35:39AM -0600, Dick Hollenbeck wrote:
> I got rid of the Return function prefixes, which seem obvious to me.  (I did not replace
> them with a "Get" prefix, which I never got.  When you have a Set*(), you can have a
> Get*(), otherwise I'm going lean.)

I suppose that's conventional naming in C++ and Java. And probably most
of the getter/setter based ones... the Return thing is actually
strange, I never did see it around.

> That accounted for probably at least 10,000 lines if you were to do a line count on a patch.

That will be painful to merge :D However that would be useful in trunk,
too, since it's cleanup and not kiway related.

> That is where the KIWAY(s) live.  There is only one KIFACE for each DSO.  Not all DSOs are
> KIFACEs because not all would be a first tier DSO.  2nd tier DSOs, at least one, will be
> coming as part of this work, and will have nothing to do with the KIWAY alchemy.
> 
> Got that?

Uhmmm... 2nd tier are simply libraries then or not interfaceable
executables or what?

Sounds needlessly complicated but anyway it's your project. Smells of
COM :D precisely of the windows explorer. One crash, the whole desktop
comes down flaming :P

What would be the advantage of loading pieces as dso instead of linking
a big kicad executable (not that a big single executable would be
optimal)? why define yet another interapp/intermodule communication
model? there is already lot of middleware ready to use for that...

Also, functionally (when the work is done) what happen if you launch
a piece of kicad when another one is open? it spawns another process or
simply 'joins' the other one (like firefox from the command line).

A more practical development issue: how you will handle the libcommon
which uses different internal units for each program (nano for pcbnews,
mils for eeschema and I don't remember gerbview)?

-- 
Lorenzo Marcantonio
Logos Srl