[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
gEDA-bug: [Bug 699813] Re: gEDA configuration needs per-page values
** Changed in: geda
Importance: High => Critical
** Changed in: geda
Status: New => Triaged
** Description changed:
- 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).
+ Â- 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).
+ Â- 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.
+ Â(a) Make per-page configuration stores, linked to the PAGE structure.
- (b) Introduce some sort of per-directory datastructure.
+ Â(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 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.
+ Â- gschem GUI behavioural preferences.
- - Color maps (forcing per-user color maps is beneficial for help
- color-blind users).
+ Â- 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).
+ Â- 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.
+ ÂÂÂÂBugs arising from the lack of per-page configuration should be
+ ÂÂÂÂmarked as duplicates of this bug.
** Description changed:
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).
+ ÂÂÂ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.
--
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:
Triaged
Bug 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) 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.
_______________________________________________
geda-bug mailing list
geda-bug@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-bug