kicad-developers team mailing list archive
Mailing list archive
Re: Re: New coding guidelines.
Dick Hollenbeck <dick@...>
Mon, 05 Jan 2009 08:32:33 -0600
Thunderbird 18.104.22.168 (X11/20081125)
2009/1/5 Dick Hollenbeck <dick@...>:
We may have to start getting more specific for this to be a fruitful
discussion. We will have to track down the code that is using these
hard coded paths. And see what facilities are using them, and if they
need to be hard coded.
I don't have a problem with a single global config file with a hard
coded name being put into a location that can be known ahead of time.
And from that config file other data files should be findable.
Anyone else have thoughts on this?
Hard coded file is a nice and clean solution under Linux (f.e.
/etc/kicad.conf or /etc/kicad/default.conf or even others). As idea if
.ini files were dropped under Windows some time ago, KiCad could be
enabled to hold such data in system registry (this would be configured
by Installer). This solutions may enable single installation to be
configured individually for different users as it is done in plenty
commercial software packages.
I like your idea about the user specific configuration data. That can
be done by choosing a user specific, yet still well known, place to
store the master config file. This can be done in a platform
independent way, i.e. without requiring use of the Windows registry (a
registry which has been unnecessary from the day it was conceived).
Jean-Pierre is probably sitting back and saying, but this is almost what
we are already doing :>)
Most likely we just need to pay some new attention to the issue and
clean up any deficiencies so the goals of this thread can be
fulfilled. I also think some tweaking to the CMakeLists.txt install
support need to be done.