kicad-developers team mailing list archive

[Tomasz Wlostowski <tomasz.wlostowski@xxxxxxx>]

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