Index: groups.html =================================================================== --- groups.html (revision 2105) +++ groups.html (revision 2106) @@ -1,4 +1,112 @@
+This works well for a small amount of settings but lack of categories or +hierarchy (or sets or groups) makes it harder to understand what setting +does what and orients users to just accept defaults. After a while it +also makes programmers think twice before adding a new setting, +increasing the crowd in a bag. This in turn results in a less configurable. +
+Introducing a hierarchy of settings can solve these problems by grouping +and categorizing settings. If the user is interested in how footprints are +searched, he can ignore the settings the editor/ subtree has. It is also +easier to save and reload selectively: when the hierarchy is done right, +closely related settings end up in the same category (thus the same subtree). +Thus saving or loading a subtree can fully save or restore a property of the +program, even if that property is affected by multiple settings. + +
+Details/constraints: +A valid path unambiguously identifies a setting (or a setting group). Settings +and groups always have exactly one parent (except for the root group that +has no parent). There is only one root of the config tree. +
+The main groups in the logical tree are: + +
(root) | (config root) + | ||
| | + | ||
+- rc | run control (program startup) + | ||
| | + | ||
+- design | some default settings of a new design; minimum/maximum value of some design settings + | ||
| | + | ||
+- editor | how the pcb editor behaves - independent of HIDs or the GUI + | ||
| | | | + | |
| | +- increments_mm | interactive increment/decrement steps when active unit is mm + | |
| | | | + | |
| | +- increments_mil | interactive increment/decrement steps when active unit is mil + | |
| | | | + | |
| | +- view | default view parameters + | |
| | + | ||
+- appearance | how the GUI looks like - common to all GUI HIDs + | ||
| | | | + | |
| | +- color | layer colors, GUI colors, misc design colors + | |
| | | | + | |
| | +- pinout | pin label properties + | |
| | | | + | |
| | +- messages | message window properties + | |
| | | | + | |
| | +- misc | non-GUI settings handled by the GUI HIDs + | |
| | + | ||
+- plugins | dynamic subtree for various plugin settings + | ||
| | | | + | |
| | +- foo | all settings of the imaginary foo plugin are registered in this group + | |
| | + | ||
+- utils | dynamic subtree for various plugin settings + | ||
| | + | ||
+- bar | all settings of the imaginary bar utility are registered in this group + |
+In plugins/ each plugin should create a group for its own settings. What +this subtree should contain depends on what plugins are actually loaded. +The benefit of this approach is that plugins can use the central config +infrastructure instead of inventing their own config files. This makes +user's life easier on many levels: single config syntax to learn; uniform +GUI (gtk HID's preferences window) to change all settings; uniform way to +save/restore parts of the settings. +
+The utils/ subtree is very similar in all aspects except that it is for +external utility programs. Utils that are closely related to pcb-rnd, such +as gsch2pcb-rnd, should work from the same configuration (e.g. to +make sure the same footprint paths are searched). If they already load the +pcb-rnd config files it's easier to keep their settings in the same tree, +in the same format. +
+Pcb-rnd doesn't generate warning for unrecognized settings in dynamic subtrees. +This lets the user configure plugins that are not always loaded and let util +settings sit in their subtree. + +