1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title> pcb-rnd - config groups </title>
<meta http-equiv="Content-Type" content="text/html;charset=us-ascii">
</head>
<body>
<H1> The new config system in pcb-rnd </H1>
<H2> grouping - flat vs. tree </H2>
The original settings and HID attribute system in pcb were both flat:
basically a list of type:key=val triplets. All settings in a few big bags;
which bag sometimes doesn't depend on some logical categorizing, but
historical reasons (e.g. which part of the code needs the given setting).
<p>
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
system.
<p>
Introducing a hierarchy of settings can solve these problems by grouping
and categorizing settings. If the user is interested in how footprints are
searched, they 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.
<h2 id="tree"> pcb-rnd config tree </h2>
The config tree, the full tree is, something that exists in memory. Actual
config files often contain only a subset of the tree. Multiple config files
(e.g. system level, user level, settings from the board file) are loaded and
merged to form the final config tree. The hierarchy of the tree is represented
by setting groups, which are like directories on a file system. Actual settings
are always leaves of the tree, placed in a specific group at any level (just
like in file systems). A full <i>path</i> to a setting is written like a
path on a file system: group1/group2/item, where group1 and group2 are
names of setting groups and item is the name of the setting. Note: unlike
with real file systems, the leading slash (representing the root) is omitted.
<p>
Details/constraints: <small>
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. </small>
<p>
The main groups in the logical tree are:
<dl><dd>
<table border=0 cellspacing=0 cellpadding=0>
<tr><td colspan=2> (root) <td width="30%"> <td> (config root)
<tr><td> | <td colspan=2> <td>
<tr><td colspan=3> +- rc <td> <a href="tree/rc.html"> run control (program startup) </a>
<tr><td> | <td colspan=2> <td>
<tr><td> | <td colspan=2> | <td>
<tr><td> | <td colspan=2> +- path <td> <a href="tree/rc_path.html">paths automatically set up by the program at startup - do not specify these </a>
<tr><td> | <td colspan=2> <td>
<tr><td colspan=3> +- design <td> <a href="tree/design.html">some default settings of a new design; minimum/maximum value of some design settings </a>
<tr><td> | <td colspan=2> <td>
<tr><td colspan=3> +- editor <td> <a href="tree/editor.html"> how the pcb editor <i>behaves</i> - independent of HIDs or the GUI </a>
<tr><td> | <td colspan=2> | <td>
<tr><td> | <td colspan=2> +- increments_mm <td> interactive increment/decrement steps when active unit is mm
<tr><td> | <td colspan=2> | <td>
<tr><td> | <td colspan=2> +- increments_mil <td> interactive increment/decrement steps when active unit is mil
<tr><td> | <td colspan=2> | <td>
<tr><td> | <td colspan=2> +- view <td> <a href="tree/editor_view.html">default view parameters</a>
<tr><td> | <td colspan=2> <td>
<tr><td colspan=3> +- appearance <td> <a href="tree/appearance.html">how the GUI <i>looks like</i> - common to all GUI HIDs </a>
<tr><td> | <td colspan=2> | <td>
<tr><td> | <td colspan=2> +- color <td> <a href="tree/appearance_color.html">layer colors, GUI colors, misc design colors </a>
<tr><td> | <td colspan=2> | <td>
<tr><td> | <td colspan=2> +- pinout <td> <a href="tree/pinout.html">pin label properties </a>
<tr><td> | <td colspan=2> | <td>
<tr><td> | <td colspan=2> +- messages <td> <a href="tree/messages.html">message window properties </a>
<tr><td> | <td colspan=2> | <td>
<tr><td> | <td colspan=2> +- misc <td> <a href="tree/misc.html">non-GUI settings handled by the GUI HIDs </a>
<tr><td> | <td colspan=2> <td>
<tr><td colspan=3> +- plugins <td> dynamic subtree for various plugin settings
<tr><td> | <td colspan=2> | <td>
<tr><td> | <td colspan=2> +- <i>foo</i> <td> all settings of the imaginary <i>foo</i> plugin are registered in this group
<tr><td> | <td colspan=2> <td>
<tr><td colspan=3> +- utils <td> dynamic subtree for various plugin settings
<tr><td> <td colspan=2> | <td>
<tr><td> <td colspan=2> +- <i>bar</i> <td> all settings of the imaginary <i>bar</i> utility are registered in this group
</table>
</dl>
<h2> dynamic subtrees </h2>
The plugins/ and utils/ subtree are <i>dynamic</i>, which means their contents
are not defined by core pcb.
<p>
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 (preferences dialog) to change all settings; uniform way to
save/restore parts of the settings.
<p>
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 and
should work from the same configuration.
If they already load the
pcb-rnd config files it's easier to keep their settings in the same tree,
in the same format.
<p>
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.
<h2> what happens to all these settings </h2>
After loading all config files they are merged: if the same setting is
described in multiple files, the higher priority wins or if the setting is
a list (e.g. library search paths) the items are merged in a final list.
At this point the full logical config tree is built. Next the textual values
from the logical tree are converted into binary (native C values like
"long int" or "double") and are saved in C variables for the code to
access them directly.
<h2> [hidlib] settings </h2>
<p>
Settings marked with [hidlib] are those that are shared among all
applications based on pcb-rnd's hidlib. They have the same syntax
and meaning in all those applications.
</body>
</html>
|
