gEDA-bug: [Bug 699813] [NEW] gEDA configuration needs per-page values

[Peter TB Brett <peter@xxxxxxxxxxxxx>]

Public bug reported:

 affects geda
 tag libgeda gschem gnetlist 
 importance high

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).

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.

** Affects: geda
     Importance: High
         Status: New


** Tags: gnetlist gschem libgeda

-- 
You received this bug notification because you are a member of gEDA Bug
Team, which is subscribed to gEDA.
https://bugs.launchpad.net/bugs/699813

Title:
  gEDA configuration needs per-page values

Status in GPL Electronic Design Automation tools:
  New

Bug description:
   affects geda
 tag libgeda gschem gnetlist 
 importance high

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).

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.





_______________________________________________
geda-bug mailing list
geda-bug@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-bug