kicad-developers team mailing list archive

[Jon Evans <jon@xxxxxxxxxxxxx>]

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.charras@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
> > 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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>