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.
On Thu, Dec 1, 2016 at 3:24 PM, Wayne Stambaugh <stambau...@gmail.com>
> 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:
> 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 : 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
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