kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 6/22/2011 2:37 PM, Vladimir Uryvaev wrote:
> 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, 

Under and overflow checking is one place where object oriented design has the
potential to be more robust than macros.  It also can help prevent the math
issues when mixing types.

> 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? ;)

In the free software world, this always the bottom line.  We can talk at length
on fixing Kicads coordinate scaling issues.  We've done so several times since
I've been involved in the project and it has never resulted in any code that
has been committed to the project.  In the end, Vladimir has stepped forward
and has offered to help fix the problem.  Thank you Vladimir.
> 
> 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? 
> ;)
> 

I don't know if you missed the discussion but the SWEET syntax is unitless.
When it is complete, schematics will not have any units.  Scaling will be done
when printing and plotting according to the selected paper size.  This was
discussed on the mailing list when I was drafting the file format
specification.  That being said, the PCB file format can not be unitless for
obvious reasons and the new schematic file format is a long way from completion.

Wayne