gEDA configuration needs per-page values

[Peter TB Brett]

At the moment, gEDA applications can only have one application-wide
value for any configuration parameter, even if they load schematics
and/or symbols from directories with conflicting configuration values
set in their per-directory rc files.

Additionally, for some configuration parameters, the value in the rc
files loaded at application startup is used, whereas for others the most
recent value set is used.

This problem manifests itself in a number of different ways, including:

 - Different behaviour depending on the initial working directory when
   a gEDA application is launched (bug 698574).

 - Duplicate component and source libraries appearing in gschem when
   schematics are loaded from more than one directory (bug 698814) or
   more than once from the same directory (bug 698492).

The only way to correct this problem is to allow more than one set of
configuration values to co-exist in a libgeda application.

There are a number of possible ways to approach such a solution:

 (a) Make per-page configuration stores, linked to the PAGE structure.

 (b) Introduce some sort of per-directory datastructure.

Option (a) seems preferable, because it requires the least amount of
disruption to libgeda datatypes and API.

On the other hand, it *doesn't* seem necessary at this stage to
distinguish between system configuration and user configuration -- these
could perhaps still be considered as "global" configuration. However,
it would make sense to make sure that the per-page configuration "falls
back" on global values if they are not specified in the local rc file.

Some configuration parameters don't currently make sense to allow on a
per-page basis. These include:

 - gschem keymapping & menu layout (these are currently done in a way
   that isn't at all compatible with being changed from page to page in
   a gschem session).

 - gschem GUI behavioural preferences.

 - Color maps (forcing per-user color maps is beneficial for help
   color-blind users).

 - scheme-directory (if this is accessible from local rc files, it
   allows maliciously crafted designs to run arbitrary code).

So any such per-page configuration mechanism must have an easy way to
always obtain global values in preference to local ones.

    Bugs arising from the lack of per-page configuration should be
    marked as duplicates of this bug.

[John P. Doty (jpd-noqsi)]

"(a) Make per-page configuration stores, linked to the PAGE structure."

The PAGE structure is a libgeda thing, but the problem also affects schematic processing scripts that don't employ libgeda. So the first step is to clearly define syntax and semantics of the files involved. Then worry about implementation in libgeda.

[Peter TB Brett (peter-b)]

The "syntax and semantics" have already been clearly defined, and the necessary APIs for working with them have already been implemented in libgeda (the EdaConfig class in the C API, and the (geda config) module in the Scheme API). They were released in 1.9.0.

The configuration is stored using the standard freedesktop.org key-value file format (http://freedesktop.org/wiki/Specifications/desktop-entry-spec). There are system, user and per-project configuration files. If you are running gEDA/gaf 1.9.0 or a more recent git version, the `gaf config' tool can be used to inspect and modify the gEDA configuration (see `man gaf'). This may be a good solution for programs that wish to use the gEDA configuration store without implementing a full .desktop parser (e.g. shell scripts).