kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

On 3/16/2017 3:03 PM, jp charras wrote:
> Le 16/03/2017 à 11:21, John Beard a écrit :
>> Hi JP,
>>
>> Thank for checking this. Internal units always confuse me, since
>> they're always different and nothing in common can ever use anything
>> to do with IUs, as they're only defined in some end executables.
>>
>> How should this be done correctly?
>>
>> Cheers,
>>
>> John
>>
> 
> IUs are not very easy to handle, and currently I am not very happy by the way they are handled.

Me neither.  I've never been a big fan of compiling the same source code
file multiple times (see include/convert_to_bui.h) depending on a
definition specified at compile time.  I would much rather see some type
of abstract class be used to define the app specific internal units.  Of
course you would have to modify the tools to use this object to provide
the proper internal units.

> 
> About the GAL layer, sorry, but I am not a GAL specialist.
> However I just know this issue is serious and must be solved.

This makes me reluctant to merge this patch even though it sounds like
this issue already exists elsewhere in the "common" tool framework.  It
also means that none of the "common" gal tools that use nanometer units
will be usable in the schematic editor and no I don't think nanometer
units make any sense for the schematic editor.

> 
> Until now, GAL was used only by Pcbnew.
> Unfortunately, in a few places, I saw a conversion to nanometers using fixed scaling factor.
> (A golden advice I learned when writing Kicad code: do not use a fixed scaling factor in code)
> 
> Now GAL is very near to be used by other applications.
> Conversion to nanometers just by using a fixed scaling factor is therefore a bug, and from my point
> of view, even in Pcbnew.
> Who know: we could change one day the internal unit value. It already happened.
> 
> I just leave guys who have a good knowledge of the GAL code taking the best decision.
> 
> Thanks, John.
>