kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 06/09/2013 02:04 PM, NHays Terrace wrote:
> It seems to me that the coordinate origin being up and left of the sheet is
> rather arbitrary.
> I can understand that you must start somewhere and that the system needs an
> absolute origin.
> But when I relocate the grid origin, I would think that the XY status bar
> report should move with it.
> I am used to placing a fiducial on the board (or off if needed)  and having
> everything relative to that point.
> That makes it easier when I am given a mechanical spec for connector
> placement, etc..
> The absolute XY report seems completely useless to the designer, unless they
> are comparing objects to statements in the files directly.
> If the origin is bumped around and a return to abs 0,0 is desired, there
> could be a command to do so.
> Using the spacebar and relative coordinates are highly useful for short term
> measurements and placements.
> But having to relocate to the fiducial is problematic - the grid location
> isn't reported, so what to do?
> When bumping from mm to mil and back, I find I can't drop the grid right on
> the old fiducial unless I make the grid ridiculously fine.
> Even then it is not accurate, just really close.
> What is missing is a selectable 'snap' to both grid and/or graphic element.
> Can someone elucidate the rationale for not displaying grid coordinates?


a) It wasn't until relatively recently that you could re-anchor the grid at other than the
origin.

b) screen real estate

c) extra information sometimes is indecipherable from noise.  It requires greater focus on
the part of the information reader.


But I like the idea, since I have a big screen.   I am most worried about c).  Others will
worry about b), they want to run kicad on a computer with an LED for a screen.


Maybe you can submit a patch which puts an alternate set of coords into a spinner.  I
would love to see origin coords and grid coords compete for visibility within a spinner,
each with a different background to tell me quickly what I am looking at.  Then I don't
have to focus my attention on which of the two I want to read.



> 
> Perhaps a simple solution would be to have three coordinate reports:
> absolute, grid, and relative(spacebar).

See above, finding what you need gets to be an issue, even if you have the real-estate.  A
"focus assisting" agent like the spinner with colored background is my suggestion.


> 
> And while I'm on the subject, the long list of grid spacing choices should
> display both "0.1mil" and "0.1mm" because "0.437259" is meaningless.

Possibly there are room for improvements here.  Certainly mm should now not take a back
seat to imperial units.


> I think I would like to have the proposed three coordinate status reports to
> tag the numbers with the units.
> For example, if the global selection is in mm, but the grid is in mil and
> relocated, then you might have on the status bar:
>    ABS X:28.5750mm Y:12.0000mm   GRID x:1.1250mil x:2.5000mil   REL
> dx:0.4239mm dy:1.3890mm


Not thrilled about the units.  Too much information is indistinguishable from noise.


> 
> With this functionality, I am aware of both unit systems.
> I never have to piece together in my head the current modality.
> I don't have to do strange things to anchor grid or relative measurements in
> mixed coordinate designs.
> And I posit that many if not most boards have mixed coordinates since the
> parts themselves are often in different unit systems.
> 
> Of course as a software engineer, I have an opinion about coordinates in
> general.


That does not make you unique.


> Coordinates should be of a class VECTOR that is based on self-scaling units.


Opinion, and not a uniquely qualified one at that.


> Every object maintains its 'true' Vectors in its own unit, mm or mil.
> Vectors convert as needed to other units without the object or any other
> code needing to care.
> Vectors have overrides for +,-,*,/,etc... so again, code that uses them
> doesn't care about the units.
> Vectors also have methods for rotation, scaling, and polar/cartesian access.
> Units should exist for mm, mil, pixels, plotting, etc..., but mm and mil are
> the only absolutes.
> When you ask an object for its location for plotting, etc..., you specify
> the units and its Vectors convert for you (and remembers the calc for next
> time).
> This eliminates the rounding errors that are still in the program.
> When you convert for display or output, the answer always has greater
> resolution than the display device/output file.
> The errors occur only when you convert, discard the source unit, then try to
> convert back.
> 
> In the file, modules should specify the units local to their definition.
> Parts in metric stay metric, those in imperial stay imperial.
> Or any file coordinate can have the form, "0.1234mm" or "5.2mil" and that is
> how it is remembered and written back to the file.
> This way no odd-balls show up like 0.3 becoming 0.29999999.
> This is annoying when working in the files - type in a 0.3 but it changes
> when the file is saved.
> Direct file editing is SO useful for creating arrays, many similar parts, or
> converting part specs to kicad format.
> 


> So can we have grid coordinates in the status bar and grid resolution
> selection units?

I hope I answered this above.



> 
> I am _so_ going to contribute cool code before long...

Start with small contributions please.



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