Index: groups.html
===================================================================
--- groups.html	(revision 30988)
+++ groups.html	(revision 30989)
@@ -95,7 +95,7 @@
 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
+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
Index: history.html
===================================================================
--- history.html	(revision 30988)
+++ history.html	(revision 30989)
@@ -31,7 +31,7 @@
 	<li> the user has the power to change default config <a href="prio.html">priority per setting</a>; 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 board file
 	<li> the way settings are stored is flexible and extensible so that a plugin can define their subtree of settings
 	<li> ... 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
-	<li> ... the GUI (gtk's preferences dialog) thus can automatically handle the new settings
+	<li> ... the GUI (preferences dialog) thus can automatically handle the new settings
 	<li> ... 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
 	<li> ... plugins also get the multi-source, <a href="prio.html">priority-based config mechanism</a>
 	<li> ... which also means plugin settings can be automatically saved as user setting, project setting or even design setting
@@ -45,7 +45,7 @@
 features present in other software so users should be comfortable with the ideas.
 The learning curve is probably compensated by the more orthogonal system.
 The syntax is also geared for simplicity and easy use with text editors.
-Finally, the new preferences dialog in the GTK HID and config actions help
+Finally, the new preferences dialog and config actions help
 the user to explore how settings got used from all the config sources. There's
 an intended layering in complexity: simple things can be done easily without
 having to understand the whole system.
Index: index_user.html
===================================================================
--- index_user.html	(revision 30988)
+++ index_user.html	(revision 30989)
@@ -43,7 +43,7 @@
 	<li> then dispatch the values to the right component of the code.
 </ul>
 Some components may change some of the settings run-time. The trivial example
-is the GUI (hid_gtk on this diagram) that provides menus and dialog boxes for
+is the GUI (<i>preferences dialog</i> on this diagram) that provides menus and dialog boxes for
 the user to change settings. Such a change is always fed back (blue arrow)
 to the design role tree directly, from where the new value is again merged
 and dispatched along the red arrows. Changes in the design role are saved
Index: merging.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: src/merging.dot
===================================================================
--- src/merging.dot	(revision 30988)
+++ src/merging.dot	(revision 30989)
@@ -86,7 +86,7 @@
 	cli          -> CFR_CLI         [label="built during\ncommand line argument\nparsing"]
 
 
-	hid_gtk [label="the GTK HID"]
+	hid_gtk [label="the preferences dialog"]
 
 	conf_core     -> hid_gtk [weight=100]
 	conf_hid_gtk  -> hid_gtk