kicad-developers team mailing list archive
Mailing list archive
Re: Grid Support
Dick Hollenbeck <dick@...>
Fri, 05 Dec 2008 23:51:32 -0600
Thunderbird 220.127.116.11 (X11/20081125)
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.
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.
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.
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?
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.
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 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.