kicad-developers team mailing list archive

[Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx>]

On Wed, 22 Jun 2011, Wayne Stambaugh wrote:

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

Isn't almost every computation done in FP in kicad regarding drawing
code? Also IIRC the geometry classes are FP based too... so the only
place int-based would be the storage... heck, we could even say
'everything is in metres' :P

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

My proposal is: handle/save *everything* in nano/metres whatever like
the decimils today. Unit conversion is relegated only to UI, which, in
fact, is handled by 3-4 function in all (I studied that when I've done
the 'universal unit' patch which allow to type 3,2mm in an edit box even when
units are set to imperial; apart from the converter itself there were
less than 50 lines of changes IIRC, done the work in about a day). So
you *could* build your class infrastructure but at the end the
conversion functions would be called only 4 times in all the kicad
sources (and most probably these call would be in the same source file).
OOP is bad when functional is sufficient (yes, not even imperative, it's
a functional solution, too:D)

IIRC other than in the UI code for edit boxes and status line (which
both call the same functions) the only other uses for the measurement
unit are in the grid menu (which shows both of them -- but probably
calling the same conversion routines) and the plot scaling function
which is a little more involved. BTW a few days ago I tried an A3 plot
and the vertical offset was wrong, I should look to 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.

OK, my proposal instead is a simple double type (you can typedef it as
'metric_size' if you want) and 2/4 functions which are already in
place... also you can already pass it to geometric routines like kbool
or boost::polygon (don't remember the name) as is (your LENGTH class
would need getter and/or cast operators I suppose to interoperate
correctly).

My bottom line is: why keeping the unit along the datatype when
everything *except* the user don't mind about the unit itself?

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

Even better if it's unitless you would need to convert everything to
a common unit (call them metres on nano or whatevere). Just handle
everything in that unit and you'll be fine.

Since sweet is a long way from now, then, in the current file format
there should be a marker that 1) makes old kicad reject the file and 2)
tell the new kicad that the units are the metric ones (maybe there's
already a version field, I don't remember).

I'd agree with your proposal if there were a need to remember what unit
were chosen by the user when the dimension was made (i.e. the box should
say 1,2mm for a hole even when current mode is imperial but the hole was
originally specified in mm); I think that would be overkill... there
is a good euristhic to choose what unit to show: metric if 'evenly'
divisible by metric (i.e. in steps of 0.05mm which is the usual
precision of electronic manufacturing), imperial if 'evenly' castable to
mils or the current mode otherwise. Of course this could be
option-configured.

--
Lorenzo Marcantonio
Logos Srl