Hi JP, You are correct, I'm talking about the "program configuration", not the "project configuration" or "library configuration". I understand your concern about adding more maintenance burden. I think there are possible solutions that would not be significantly more complicated than wxConfig (and also be equally cross-platform) although it would definitely mean a one-time rewrite.
I think I will put together a more detailed proposal including more clear statements on what I think the benefits are as well as my analysis of the costs, and will come back with that proposal. I think the current config system is quite limiting in terms of where KiCad could go in the future, but perhaps it is easier to explain why I think that with some more concrete examples that will take me some time to write up. Best, Jon On Thu, Dec 1, 2016 at 1:46 PM, jp charras <jp.char...@wanadoo.fr> wrote: > Le 01/12/2016 à 17:44, Jon Evans a écrit : > > Hi all, > > > > Per my recent email, I'm going to be looking in to various UI/UX things, > starting with Eeschema, and > > I thought of a topic that probably warrants its own thread. > > > > Some of the things I want to propose would involve giving the user more > options for customization of > > the tool (i.e. more preferences, color themes, etc). > > > > Right now, it seems like all KiCad configuration data is stored in a > INI-style key-value file per > > binary (one for eeschema, one for pcbnew, etc) in the user's application > data folder. > > > > What do the core developers think about the possibility of > changing/expanding the way KiCad uses > > files for configuration? > > > > Some examples I thought of: > > > > - Switching to a format like YAML or JSON that allows nesting of > configuration parameters, for more > > clean configuration > > Library tables are not in INI-style key-value. > Some config settings like plot options for boards, design rules... are > stored inside the .kicad_pcb > files. > > I am thinking you are talking about other config files containing current > setting (colors, frame > position and size, last opened files...) > > These config files are managed by wxWidgets, not by Kicad. > Changing the file format means rewrite (therefore maintain) the wxConfig > classes inside Kicad, and > make them compatible between all OS. > > I am not sure this is a good idea (I mean: high cost, (very) low benefit). > > > > > > - A "configuration hierarchy" system, meaning that there are "system > defaults" for all values stored > > in a file somewhere, and when the user starts changing them, they are > creating a new file in their > > home directory that "overrides" whatever settings they have changed, > rather than updating the system > > config. This would allow the default config to be preserved if multiple > users on one PC want to > > have different local settings. It would also make it easier for people > to send config to each > > other, and to back up their config by checking it in to a Git repository > for example. Sublime Text > > is one example of a program that does this, and it works really well in > my opinion. > > > > - Splitting out certain configuration items into distinct files, rather > than using a single file for > > all config of a certain program. Color themes are one area where this > is often done in other > > programs, so that people can download/share new color themes without > having to copy/paste certain > > areas of a global config file. > > > > So, any opinions on this? Just knowing something like "never gonna > happen" versus "sounds > > interesting, send more details" is good feedback for me at this point, > that way I can know up front > > what kind of changes are likely to be accepted when I come up with more > detailed proposals. > > > > Best, > > Jon > > > > > > _______________________________________________ > > Mailing list: https://launchpad.net/~kicad-developers > > Post to : kicad-developers@lists.launchpad.net > > Unsubscribe : https://launchpad.net/~kicad-developers > > More help : https://help.launchpad.net/ListHelp > > > > > -- > Jean-Pierre CHARRAS > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp >
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
