Re: [Kicad-developers] configuration files for KiCad

[Jon Evans]

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 
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@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> >
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] configuration files for KiCad

[Wayne Stambaugh]

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

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] configuration files for KiCad

[Jon Evans]

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  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@lists.launchpad.net
> > 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@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] configuration files for KiCad

[jp charras]

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

Re: [Kicad-developers] configuration files for KiCad

[Tomasz Wlostowski]

On 01.12.2016 17:44, 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
> 
> - 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.

Hi John,

Don't have much time to answer, so I'll be short:
yes, yes, yes.

If you'll add an easy way of serializing/deserializing C++ configuration
classes (e.g. PNS_ROUTING_SETTINGS) to an appropriate section of a
config file, it would be even better ;-)

Cheers,
Tom

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] configuration files for KiCad

[Jon Evans]

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
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp