On 01.12.2016 17:44, Jon Evans wrote: > 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 > > - 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.
Hi John, Don't have much time to answer, so I'll be short: yes, yes, yes. If you'll add an easy way of serializing/deserializing C++ configuration classes (e.g. PNS_ROUTING_SETTINGS) to an appropriate section of a config file, it would be even better ;-) Cheers, Tom _______________________________________________ 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