kicad-developers team mailing list archive

[José Ignacio <jose.cyborg@xxxxxxxxx>]

eeschema uses mils, which are exactly 25400 nanometers, eeschema can be
losslessly converted to nanometers. Another advantage of using nm in
eeschema would be that it would be possible to use round metric quantities
(right now it's impossible and confusing as numbers are rounded to the
nearest mil) while being able to open older schematics losslessly.

On Thu, Mar 16, 2017 at 2:16 PM, Wayne Stambaugh <stambaughw@xxxxxxxxx>
wrote:

>
> 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.
> >
>
> _______________________________________________
> 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
>