kicad-developers team mailing list archive

[Jon Evans <jon@xxxxxxxxxxxxx>]

Thanks Wayne.  I will look in to wxConfig paths and see if I can see any
compelling disadvantages to bring up vs. JSON (note that JSON could be
handled by Boost.PropertyTree so no additional dependency).  If I can see a
clear way to achieve the things I want to propose using wxConfig, I'm fine
with that, no need to change for change's sake.

-Jon

On Thu, Dec 1, 2016 at 3:24 PM, Wayne Stambaugh <stambaughw@xxxxxxxxx>
wrote:

> On 12/1/2016 11:44 AM, 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
>
> I'm not thrilled about using YAML or JSON.  It would add another build
> dependency and I can't think of any config settings in kicad that need
> this kind of nested file complexity.  That being said, we certainly
> could clean up our current config files.  I've never been a big fan of
> prefixing the window frame name to the key (SchematicFramePos_y,
> LibeditFrameShowGrid, ViewlibFrameSize_y, etc) in on one huge section.
> I would like to see the config settings take advantage of the wxConfig
> paths so the config files would look something like:
>
> [Schematic/Frame]
> X=0
> Y=0
> Width=600
> Height=400
> [LibViewer/Frame]
> X=200
> Y=100
> Width=400
> Height=200
>
> This would certainly be a lot cleaner (more readable) than what we are
> currently doing.
>
> See http://docs.wxwidgets.org/3.0/classwx_config_base.html for examples
> using wxConfig paths.
>
> >
> > - 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.
>
> I'm OK with this.  Most of the default config settings are hard coded
> since there is no config on startup so you may have a lot of work to do
> in this regard.
>
> >
> > - 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.
>
> I'm OK with this too.  You could split out the viewer and editor frame
> settings into separate config files so they are more manageable.
>
> >
> > 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
> >
>
> _______________________________________________
> 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
>