kicad-developers team mailing list archive

[Thomas Pointhuber <thomas.pointhuber@xxxxxx>]

Hi Wayne,

I think, I was present at FOSDEM 2019 when talking about this issue.

From what I understand, the current approach requires KiCad to compile
the units for each package separately (because e.g. mapping IU<->mm is
always different). This has two big problems:

1. the same code has to be compiled multiple times.
2. there is no "true" mapping from IU to other units. When I for example
want to create a python API with one type of geometric primitives, this
is a real problem. When I want to script into eeschema and pcbnew at the
same time, how to choose the correct units?

The solution discussed was to move to 64bit and to use
constexpr/templates handling unit conversion. So a programmer can for
example enter 2mm and the compiler automatically converts it into the
internal unit like nm.

I'm still in favour of improving this. The same with angles.

Regards,
Thomas


Am 13.02.20 um 15:46 schrieb Wayne Stambaugh:
> Hi Johannes,
> 
> Thank you for your suggestion but the internal units for each format
> were chosen for a specific reason.  There really is no justifiable
> reason to change them as they have been carefully selected based on the
> requirements of the objects they represent.  Conversion code is provided
> for each internal unit so plotting to standard units such as
> millimeters, inches, etc is trivial.  I'm not opposed to adding support
> for changing the plot units.  I am opposed to changing the internal units.
> 
> Cheers,
> 
> Wayne
> 
> On 2/13/20 9:32 AM, Johannes Pfister wrote:
>> The KiCAD code uses all kinds of different units for distances.
>> Amongst other things I found:
>>   nm: pcbnew internal units
>>   10nm: Gerbview internal units
>>   100nm EEschema internal units
>>   1um: PL-Editor internal units
>>   0.1mil (2.54um): SetViewport
>>   1mil (25.4 um): WS_DRAW_ITEM_BASE and GetSizeMils
>> And the native File formats use mm (pcbnew) and mil (EEschema).
>> Something like SVG exports in 0.1 mil steps. I think that this is not
>> very consistent and something like a PLOTTER class needs to handle
>> different IU-sizes.
>>
>> My idea is to rewrite the internal units so that nm are used
>> everywhere inside the source code, and only parts that write or read
>> files and display data to or read data from the user should convert it
>> to another unit system. I don't want to change any file formats.
>> That would make it a bit more straightforward, more consistent, metric
>> and an SVG-Plotter would use a metric step size. The disadvantage
>> would be that there would be an about 2m or 4m limit in every
>> direction, assuming int is 32 bit, which is AFAIK true for all
>> platforms KiCAD current supports.
>>
>> Before i rewrite code, can you say what you guys think about it?
>>
>>
>> Johannes Pfister
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>

Attachment: signature.asc
Description: OpenPGP digital signature