← Back to team overview

kicad-developers team mailing list archive

Re: Converting KiCAD to metric units: The approach

 

Lorenzo Marcantonio wrote:

> I completely disagree. This is too complex for what we want... in fact
> OOP most of the time only complicates life but that's IMHO:P

Strange to hear this from active developer...

At first, don't you think, that if some programmer make his life complicated 
using OOP it's only programmer's problem, not OOP problem. End even if most of 
the programmers do so it does not make it OOP problem ever. :)

Second, it seems I happened to joke you, there's no real OOP:), just 
exploiting "C++ view of OOP". The class (ok, data type) is made to avoid 
mixing between nondimensional numbers and lengths.

> In the past the best way do defeat the issue was agreed to be the common
> divider, something like 200nm or such. Just use it instead of the
> current decimil and fix the scaling factors in the conversions (which
> are mostly in the common/ code). Voilà, metric kicad with no rounding
> issues...

Is there any contradiction with something previously said? No, there's just a 
C++ construct incorporating storage and length conversion facilities. Would 
you think lots of #defines and bulky c-macro-style code would be better?

When it implemented all the lengths should use defined class so have same scale 
factor.

And finally, did you try to do your "Voilà"? Find all the scaling code with 
hard-coded constants (254's, 3937's and many weird others), fight integer 
overflows? Do it all in only ints without idea how to decide where are mils, 
decimils, millimeters in all whose variables? I did this, and say, it's not so 
simple as you imagine. My approach is seem to be most clear and bug-avoiding 
one i can work out. Do you know better one? But why did not you already 
proposed it? ;)

I commited a file 'include/length.h' which implements the LENGTH class; it's 
not included anywhere yet. You an all can see it now.
This class acts mostly like ordinary numeric value (+ - * / etc work fine). 
Also there's LENGTH_XY which is 2D version, and analogous to wxPoint/wxSize.

> But IMHO it should be done *together* with the new file format so to
> have only one format conversion to do... i.e. traditional kicad in
> decimils and SWEET/sexp/whatever in nano units...

Don't you think nano development should be *started after* SWEET/sexp is done? 
;)

-- 

--- KeyFP: DC07 D4C3 BB33 E596 CF5E  CEF9 D4E3 B618 65BA 2B61


Follow ups

References