kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #26864
configuration files for KiCad
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.
Best,
Jon
Follow ups