I’ve created a fork of the KiCad sources on GitLab to track the modifications I’ve made to allow user-selected display origins in PCBnew. My hope is that this will generate some suggestions and testing by the community.
At this point there are two branches available, both for 5.1.x:
I’ve used the 5.1.5 branch fairly extensively over a number of months and believe it to be stable. The 5.1.6 branch is essentially untested (it builds and runs) as it was only created this morning.
Either will require you to build from sources; I am not going to be providing any binaries.
At one point I had equivalent patches for the v6 development branch, but they are so old and out of date that I’m not even going to post them. I do intend to add equivalent functionality to the v6 release, though I will not promise any sort of schedule.
The displayed Y-axis can increase going up the page, or down (default).
The displayed X-axis can increase going right (default) or left.
The displayed origin can be any of: the page (default), user-settable grid, or user-settable “Aux” origin.
Changing any of the display options does not alter the board file so the choice can be made on a per-user basis. Obviously, moving the grid or Aux origins will be recorded in the board file.
The grid origin serves a different purpose. It defines the starting point for the grid, i.e. the point which is always on the grid. The grid origin must be independent from the coordinate origin, otherwise it looses its original purpose (pun intended).
Moving all objects is logically the same than setting a new coordinate origin, but for some reason the “page” is tied to the absolute coordinates. I would have preferred being able to set the actual coordinate origin (possibly internally moving everything, including the page) without all this confusing hassle with different origins, but whoever implements this, decides, I think.
@RRPollack, I hope you will find time to migrate this to 5.99. It’s useless for the KiCad project in 5.1 because it won’t be merged there anyways. Personally I’d rather test it for 5.99, and will do when it’s ready for that.
I’ve been maintaining the v5.x patches for my own use, since I was doing a board design myself and didn’t want to deal with the instability of the v6 development branch. Pushing them out for V5.1.5 was a matter of setting a git remote and pushing, and the v5.1.6 patches only required one small tweak.
The v6 equivalent will take some time, as there has been a lot of development since I last looked at that branch. But I expect the user-visible changes will be the same.
I have hacked around this with a workaround, which is pretty simple yet effective.
My current project is a board for a rack mounted assembly and the goal is to make different boards with the same outline and connector location.
My workaround is to place a reference pin of the connector at (127,127), which makes it line up on both imperial and metric grids.
This way I can use a grid of 100mil to be compatible with Vero board, and use a metric grid for the board outline, hole locations etc without, having to fiddle with grid or coordinate offsets.
I prefer to keep stuff as simple as possible (but not simpler) and tend to work with what I have. Adding extra options to hack the coordinate system in KiCad is an “extra complication” for me, which I want to avoid.
However, I do admit that the current coordinate system in Pcb is a bit primitive with (0,0) fixed in the left top corner, and there have been discussions on improving on this. I even think (but am not sure) it got to a point to revise and update coordinate offsets and direction in Pcbnew in a future KiCad version. Are you aware of this and is there some kind of coordination with your mod and this, or are you working on your own?
I started working on this more than a year ago. It’s been discussed both in KiCad issues and the dev mailing list. The v6 patches I mentioned were submitted for merge but one of the core devs objected on a technical detail. It’s only now that I’m finding time to work on it again.