← Back to team overview

kicad-developers team mailing list archive

Re: Grid Support


1) I would like a little more zoom range on the top end, especially within PCBNEW. Another power of 1.5 or 2.0 larger.

Agreed. I was thinking more linear steps sizes. I was thinking in
terms of percentage rather than powers of two.

2) I think the magnification steps are just barely too large. Meaning I think there should be a smaller zoom step than a power of 2 at each click along the way. Note that I am not asking for a super general solution here, just a minor tweak that would give us something less than 2 times magnification at each click, and this factor (step) can remain fixed. I just think 1.5 might be nice to try if it can be made into a compile time option.

I could initially implement it as a compile time option. In the future
it might be nice to be add user definable zoom levels. If you really
wanted to be slick, you could vary the zoom rate relative to the rate of
change of the mouse wheel. I don't see that happening anytime soon.

Just an

#if 0

is good enough for me. If it works and feels OK, then the old code gets junked a week later. I wouldn't mess with the CMake configuration variables, not called for.

I don't know that it would be any more difficult than the grid changes I
just made. I think I could get something done over Christmas break. I
can keep the existing zoom levels as CMake build option. You could turn
it on and off at build time with a CMake option.

While I'm at it I have some questions of my own.

1) Since the addition of wxAboutDlg, Kicad cannot build against versions
of Kicad prior to 2.8. There are quite a few wxWidgets version tests
version well before 2.8. Does anyone object to me removing them from
the source as I find them? They only clutter up the source code and
serve no purpose anymore.

No objections from me.

2) The current user defined grid setting is actually saved in the .brd
file of the project that you are working. In other words, your custom
grid is no longer defined when you create a new project or open a
different one. Shouldn't this setting be saved at the application level?

Not sure I agree. I like my settings in the board so that when the board is loaded then I get them set automatically. That is why I put the layer names into the board.

3) Will anyone be terribly upset if I figure out a clean way to load and
save configuration (both project and application) settings without
having to use global variables? It is widely accepted that using global
variables is a frowned upon software development practice. I personally
would like to see them all go away. If no one strongly objects, I will
start chipping away at them.

I think many of them are already in a struct or class. If you just add member functions to load them and save them, make sure they are in a class, then it really does not matter whether that class is instantiated globally or tied to a board tree. Since the app can only handle one board at a time, I rank this at a slightly lower priority than you, but you might be seeing something that I don't. Although I do not disagree with your view that globals in general are not cool, sometimes it is difficult to give access to them from everywhere without making them global. For example if a contained structure needs them and they are in the containing structure above that holds the contained structure, this means giving access to the parent from a child, and that is equally less ideal as having globals.

I have not checked the tracker lately for bugs and enhancement requests. There is probably a way to make some folks happy by working your way through some of those items once you knock off your own personal highest priority items.