| 2011-01-07 13:07:13 |
Peter TB Brett |
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.
|
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.
|
|
| 2011-01-07 13:08:31 |
Peter TB Brett |
description |
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.
|
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.
|
|
