[devhelp] todo: move section about DhSettings to corresponding *.c file

[Sébastien Wilmet <swilmet src gnome org>]

commit c7a30a7fd6babe31aab0cef4fc22bb5d770afb7f
Author: Sébastien Wilmet <swilmet gnome org>
Date:   Sun Jan 27 12:52:54 2019 +0100

    todo: move section about DhSettings to corresponding *.c file
    
    And improve the comment.

 TODO                  | 30 +-----------------------------
 devhelp/dh-settings.c | 38 ++++++++++++++++++++++++++++++++++++++
 2 files changed, 39 insertions(+), 29 deletions(-)
---
diff --git a/TODO b/TODO
index 3d09d1aa..6afbe271 100644
--- a/TODO
+++ b/TODO
@@ -38,32 +38,4 @@ See also the roadmap on the wiki.
 Improve DhSettings
 ------------------
 
-For the software product line, one thing that is not present in Tepl (so I
-needed to do the first iteration in Devhelp), is DhSettings to handle the
-GSettings in a library. The goal is of course to have the minimum amount of
-code or work to do in the applications.
-
-But I'm not entirely satisfied by the current DhSettings. But to make it better
-it would require lots of boilerplate code, so I was maybe thinking about a code
-generation tool that reads the GSettings XML schema and creates a GObject class
-with some properties and functions for each key. Then DhSettings would come on
-top of that generated class (either as a subclass or using it by composition)
-to add more specific functions like is_book_enabled(), set_book_enabled(), etc.
-
-The code generation tool would do something along those lines:
-- Add a property of type GVariant for each GSettings key.
-- Add getters/setters for the GVariant properties (bonus if for simple types
-  like integers, strings, booleans, the getters/setters use the appropriate
-  GLib type, not GVariant. Or find a way to make it convenient to use GVariant
-  to get/set the properties).
-- Add bind_to_key() functions, to bind a GVariant property to its corresponding
-  GSettings key.
-- For each key, add another property of type boolean to know whether the
-  GVariant property has been bound to the GSettings key. Same name as the
-  GVariant property, but with the -bound suffix.
-- Add one bind() wrapper function with an API like g_settings_bind(), but calls
-  g_object_bind_property() if -bound property is FALSE, and calls
-  g_settings_bind() if -bound property is TRUE, to take advantage of the
-  writability of the GSettings key.
-- If more flexibility is needed, add getters to get the GSettings objects,
-  those can be used for the keys where the -bound property is TRUE.
+See the comment in dh-settings.c.
diff --git a/devhelp/dh-settings.c b/devhelp/dh-settings.c
index 873f55fa..e7f09417 100644
--- a/devhelp/dh-settings.c
+++ b/devhelp/dh-settings.c
@@ -72,6 +72,44 @@
  * defined by the libdevhelp (not the app).
  */
 
+/* TODO Possible DhSettings improvements:
+ *
+ * GSettings is usually used only in an application, not in a library. The
+ * purpose of DhSettings is to have the minimum amount of code or work to do in
+ * the applications, with the goal to create a software product line for
+ * Devhelp (create several similar products based on the libdevhelp).
+ *
+ * But I'm not entirely satisfied by the current DhSettings. But to make it better
+ * it would require lots of boilerplate code, so I was maybe thinking about a code
+ * generation tool that reads the GSettings XML schema and creates a GObject class
+ * with some properties and functions for each key. Then DhSettings would come on
+ * top of that generated class (either as a subclass or using it by composition)
+ * to add more specific functions like is_book_enabled(), set_book_enabled(), etc.
+ *
+ * The code generation tool would do something along those lines:
+ * - Add a property of type GVariant for each GSettings key.
+ * - Add getters/setters for the GVariant properties (bonus if for simple types
+ *   like integers, strings, booleans, the getters/setters use the appropriate
+ *   GLib type, not GVariant. Or find a way to make it convenient to use GVariant
+ *   to get/set the properties).
+ * - Add bind_to_key() functions, to bind a GVariant property to its corresponding
+ *   GSettings key.
+ * - For each key, add another property of type boolean to know whether the
+ *   GVariant property has been bound to the GSettings key. Same name as the
+ *   GVariant property, but with the -bound suffix.
+ * - Add one bind() wrapper function with an API like g_settings_bind(), but calls
+ *   g_object_bind_property() if -bound property is FALSE, and calls
+ *   g_settings_bind() if -bound property is TRUE, to take advantage of the
+ *   writability of the GSettings key.
+ * - If more flexibility is needed, add getters to get the GSettings objects,
+ *   those can be used for the keys where the -bound property is TRUE.
+ *
+ * That code generation tool would be useful outside Devhelp, for any project
+ * that wants to use GSettings in a library or software product line, basically.
+ * More generally, there needs to be a reflection on how best to use GSettings
+ * in a library.
+ */
+
 /* libdevhelp GSettings schema IDs */
 #define LIBDEVHELP_GSCHEMA_PREFIX       "org.gnome.libdevhelp-" LIBDEVHELP_API_VERSION
 #define SETTINGS_SCHEMA_ID_CONTENTS     LIBDEVHELP_GSCHEMA_PREFIX ".contents"