[enh] New grids for GTK PCB

jopka, that is great! I like it a lot. I've tested it briefly and it sure will make designing footprints and working with a mixed English/metric layout much more pleasant.

I did some editing of the UI text to fix a typo and for grammar, style, consistency, and clarity. A patch with my text edits, to be applied on top of your patch is attached.

Thanks for your effort! I hope this makes it to mainline soon.

I like this patch, but have a several problems with it.

I cannot see the points in bigger zooms. It is probably not general problem, just the points are probably too small.
Cannot the grid points be bigger or different color? Or it can be just problem somewhere on my side.

The bigger problem is that the patch is full of "TODO" stuff. I will try to look at it and sort out parts I do understand, but i can take a week or so.

BTW: I have no knowledge of Lesstiff.

@Martin Kupec:
I also encountered a zoom level that made the grid points hard to see, but then I realized it is no different from the old grid behavior. For instance using git HEAD set grid to 100 mil and zoom in several clicks and you'll have the same problem, it appears. So the solution is to hit 'G' to change grids if you want to work at really fine detail.

I would like a way to disable the dynamic visible-grid sizing as you zoom, however. It might be nice sometimes but often I would rather always have my grid dots drawn at 100 mil or 0.5 mm spacing even if I zoom out a ways (of course if you zoom out far enough that each pixel represents close to 50 mil if using a 100 mil grid then it will not be useful).

Did not apply cleanly against git head at 359a02cfe25e32aec7d2985c8f368fbfdcd954fa

This is a step in the right direction!

Notes:

* The patch file should be named *.patch

* The patch file failed to open with gedit, because the editor could not determine the encoding.

* Typo in preferences: "Grigs" --> "Grids"

* The popup help is nice for a first time read. But it gets into the way on edit of grid sizes.
Suggestion: Add a help button on the bottom of the tab.

* Current should be a check box rather than the string "Yes"

* IMHO, an individual "step" entry for every individual is a tad too fine grained.

* The concept of does not work out for me: Grid

* I did not find a GUI way to add more grids

* I miss an accel key to decrease the grid

* Suggestion: Please map next/previous grid to "[" and "]". These are the corresponding accels in gschem. Such a binding would improve interoperability of the applications.

---<)kaimartin(>---

Updated patch:

More info on mailing list (please see link above)

I gave the above patch a test run with a real project.
Notes:

1) The patch introduces config lines in the layout file. Not patched versions of PCB fail on load when confronted with these lines. The patch tries to accomondate to this by bumping the file format version. Still, this incompatibility makes the patch unusable in a heterogenous user environment. Think cooperation with collegues, use of the openGL enabled version of Peter Clifton, ...

2) I often need to work with both, mil and mm grids on the same layout. With the current version of the patch both have to be supplied by the same grid array. This is of course cumbersome. Please add a second set of grid parameters and switch between them according to a dedicated mm/mil toggle.

3) The abillity to go up and down with "[" and "]" is nice and is a step forward toward gschem/pcb interoperability.

4) Please keep [shift-g] attached to-decrease-grid-size. This would provide GUI-wise backward compatibility.

I hope to see this enhancement applied to git-head.

---<)kaimartin(>---

@KaiMartin:
1) Could "attributes" be used to store the grid configuration in such a way that new pcb files could still be opened by old pcb versions?

I too am waiting in earnest for this new grids feature to appear in pcb mainline! It would really save me a ton of time clicking through View > Grid Size > NNN mil hundreds of times.

Following up with my previous comment, I will add a reminder that pcb now stores its basic grid setting using the Attribute[] feature of the pcb file format. This could be easily expanded to store the enhanced grid data as well, and would provide full backward compatibility of the design.

I just rediscovered this in December 2014. The patch is completely bit rotten. Files have been moved, internal units have been converted to nm. Almost all hunks would have to be touched to make the patch apply again.
On top of that, the backward incompatibility mentioned above would have to be fixed before this is considered for inclusion in the main branch.

That said, I'd really like to see two or three aspects of this patch added to pcb:

a) increment / decrement the grid by a notch with hotkeys "[" and "]". Note this is not the same as incrementing by fixed amount like pcb does now.

b) a user accessible way to define preferred grid widths. I'd be fine with a simple config file. GUI centered input is nice if done properly. But experience shows that this requires quite a bit of attention to detail. When in doubt, this attention may yield more impact elsewhere.

c) two sets of predefined grid widths: metric and imperial

I stop my developement due to i (after many blind retries) can't invent new C function with non empty argument(s) into code due to C is too hard for me and not straighforward. As far as i can remember, this was very basic C task so no luck with web search. So i can with relatively few hair tearing only modify body of existing C functions. I still have enough time and want to continue my developement of patch. I will try it soon until i again stuck with C, then i write here which function i can't add.

Unfortunately, I don't see, how this is work in progress. The original author orphaned the effort and nobody else stepped up.
In addition, there were several severe problems with the approach. The way, the grid parameters were stored were disruptive. Once you had saved a layout with a copy of pcb which had the patch activated, any previous version of pcb would segfault on load. The GUI suffered from a couple of sub optimum choices of widgets. On top of that, the code is completely bit rotten by now.

However, more control on grids would be a very welcome improvement. So I'd tag this patch an optimistic "wishlist".

---<)kaimartin(>---

> So I'd tag this patch

Why "I'd"; not "I"? You can change the tag as much as anybody else.

The disruptive way of storing the grid might be gone. One can store any value with unit. There's also an attribute which says wether it's an imperial or a metric grid.

IMHO the best solution would be to keep menus as they are, adding only a single item, 'other...'. This 'other...' would open the command line and pre-type 'GridSize(' there, so the user can type whatever he wants. Biggest imaginable flexibility this way and almost no additional clutter.

I didn't do it so far because I couldn't find code to pre-type something in the command line.