the old system didn't support lists or arrays well
@@ -35,7 +35,7 @@
How to get started
Index: index_prog.html
===================================================================
--- index_prog.html (nonexistent)
+++ index_prog.html (revision 2116)
@@ -0,0 +1,8 @@
+
+
+ The new config system in pcb-rnd
+ Programmer's documentation
+
+TODO
+
+
Index: noextend.html
===================================================================
--- noextend.html (nonexistent)
+++ noextend.html (revision 2116)
@@ -0,0 +1,59 @@
+
+
+ The OLD config system in pcb-rnd
+ If the config system is too static
+
+This document describes the old situation, focusing on drawbacks for
+a purpose: to give a hint on why some of the design decisions are made
+the way they are, in the new conf system.
+
+ Settings, preferences, colors, and...
+The core implemented a so called Settings. It was a flat list of items,
+each bound to a C variable. There was a bunch of metadata attached to
+the items: name, type, description. Generic code could query or change
+the value of any setting, the C code could read and write them directly
+too. The content is saved to ~/.pcb/settings.
+
+On the downside, the actual items this system knew about was pretty much
+static, hardwired in core. A plugin could not register its own settings.
+Multiple parallel methods were present in the code to overcome this
+limitation:
+
+ - HID attributes: another way to describe name-type-metadata lists; this
+ was used to pass on some rc-like parameters to the GUI HIDs. It's also the
+ main API to describe export parameters for the export HIDs. However,
+ HID attributes is not well suited for saving plugin (or HID) user
+ preferences, it is more about a per action configuration.
+
+
- The gtk HID also saved its own settings to a separate file called
+ ~/.pcb/preferences.
+
+
- Some gtk HID settings didn't quiet fit in the preferences - the color
+ scheme can be saved in another file, usually under ~/.pcb/colors
+
+
- A random plugin could either use the HID attributes to get a limited
+ service or like the gtk HID did, had to implement its own save-restore of
+ persistent settings.
+
+
+ Meta-drawbacks
+This also introduced a more subtle drawback: the configuration was now
+scattered into different files, randomly (looking from the
+user's point of view). In other words, the actual structure did not reflect
+some logical groupping, but mostly historical or source code organizational
+reasons.
+
+In turn, this also limited (again somewhat randomly) what settings can be
+stored system-wise, user-wise, or on project or design level.
+
+Finally, handling of file search paths was not very sophisticated. There
+was the system and user configuration that reflected where the stock
+library or the user's generic library were installed. And then
+there was the per-project local footprint libs that had to be somehow
+added too.
+
+There was a hardwired way of handling the situation where multiple set
+of paths were specified. In practice it was usually possible to get this
+to work for the simpler cases, but it was not powerful enough to express
+things like "use all system and user libraries first, then the project's local
+library" vs. "the project's local library has priority over system libraries".
Index: plugin_chk.html
===================================================================
--- plugin_chk.html (nonexistent)
+++ plugin_chk.html (revision 2116)
@@ -0,0 +1,7 @@
+
+
+ The new config system in pcb-rnd
+ Plugin programmer's checklist
+
+TODO
+
Index: prio.html
===================================================================
--- prio.html (nonexistent)
+++ prio.html (revision 2116)
@@ -0,0 +1,7 @@
+
+
+ The new config system in pcb-rnd
+ Priorities
+
+TODO: needs a few design decisions before it an be documented
+