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
> 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
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
> - 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.
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : email@example.com
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp
Mailing list: https://launchpad.net/~kicad-developers
Post to : firstname.lastname@example.org
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp