kicad-developers team mailing list archive

[Dick Hollenbeck <dick@...>]

> > 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
#else
#endif

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.

Thanks,

Dick