Index: index.html
===================================================================
--- index.html (revision 5702)
+++ index.html (revision 5703)
@@ -10,7 +10,7 @@
... this led to a variety of configuration formats; using one format not always because it was better suited for the task, but for historical reasons
... this also led to a collection of config files - again not always split by boundaries of settings, but often by arbitrary boundaries of code
the old system didn't support lists or arrays well
- it didn't have a coherent concept of how settings from different sources would override eachother
+ it didn't have a coherent concept of how settings from different sources would override each other
... this resulted in the rigid structure that most of the settings could come from only one place (e.g. if it's an user setting, the design won't be able to override it)
@@ -17,14 +17,14 @@
What the new system offers
- unified format: lihata ...
-
- ... more future proof: generic markup language - easier to extend wihtout having to worry about breaking the syntax
-
- ... the configuration is represented in a tree, groupped by the nature of settings
+
- ... more future proof: generic markup language - easier to extend without having to worry about breaking the syntax
+
- ... the configuration is represented in a tree, grouped by the nature of settings
- ... there are arrays and lists
- ... a config file can overwrite a list or prepend/append to it (e.g. design-level config prepending an extra library path keeping system set paths as well)
- there are different sources of configuration, e.g. system-wise, user-wise, project-wise, etc.
-
- the user has the power to change default config priorty per setting; e.g. normally design config overrides user config, but it's possible to mark a setting from user config so strong that it overrides even the setting read from the .pcb file
+
- the user has the power to change default config priority per setting; e.g. normally design config overrides user config, but it's possible to mark a setting from user config so strong that it overrides even the setting read from the .pcb file
- the way settings are stored is flexible and extensible so that a plugin can define their subtree of settings
-
- ... since the API even makes it easier to access such settings (vs. parsing your own config file), plugins will tend to use the unified config format/system instead of inventing teir own
+
- ... since the API even makes it easier to access such settings (vs. parsing your own config file), plugins will tend to use the unified config format/system instead of inventing their own
- ... the GUI (gtk's preferences dialog) thus can automatically handle the new settings
- ... plugins don't have to implement actions to set/toggle/query their settings for the menu system, there are generic config set/toggle/query actions the menu config can use
- ... plugins also get the multi-source, priority-based config mechanism