[amtk] docs: more dev-notes

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

commit 87ac08dce1e312da31c7e8c94357bb34bc4b97d5
Author: Sébastien Wilmet <swilmet informatique-libre be>
Date:   Wed May 11 23:03:56 2022 +0200

    docs: more dev-notes

 docs/dev-notes | 21 ++++++++++++++++-----
 1 file changed, 16 insertions(+), 5 deletions(-)
---
diff --git a/docs/dev-notes b/docs/dev-notes
index 69355f4..fe1fc4e 100644
--- a/docs/dev-notes
+++ b/docs/dev-notes
@@ -15,22 +15,33 @@ Possible things to do
   placeholder). Or create a Placeholder object that contains the list of items,
   so when the Placeholder object is modified, the menu/toolbar is updated
   accordingly.
+  Or, the application can re-generate the whole submenu or a toolbar each time
+  that it is needed. Or a submenu could be created on-the-fly, upon receiving a
+  signal to open the submenu (?). In these cases, a full-blown placeholder
+  mechanism is not needed, but perhaps a few utility functions would help.
+  A good test-bed for this is the gnome-latex application.
 
 - Add one more sanity check: check that a GAction is *implemented* when (or
   after) creating a menu or toolbar item for that action? Because currently
   when the GAction is not implemented, the menu/toolbar item is just
-  insensitive, there is no warning.
+  insensitive, there is no warning, no way to know if the menu/toolbar item was
+  set as insensitive explicitly/intentionally or not.
 
 - An AmtkActionInfo could have a field for the default AmtkFactoryFlags (or to
   force some flags). For example setting AMTK_FACTORY_IGNORE_ACCELS_FOR_APP for
   the tepl-cut/copy/paste/select-all actions.
+  But it's perhaps a bit messy.
 
 - To prevent apps from modifying ActionInfos of libs, maybe seal an ActionInfo
   when it is added to a store, except for mark_as_used(). But it's maybe a bit
-  too paranoid. Or instead of sealing, have a builder, see:
+  too paranoid. Or instead of sealing, have a builder class that creates an
+  immutable ActionInfo, see:
   https://blogs.gnome.org/otte/2018/02/03/builders/
 
 - ActionInfo and ActionInfoEntry could have one more field for an identifier,
-  because when using a detailed GAction name the name is less "greppable" and
-  less easy to understand. The detailed GAction name would be the equivalent of
-  the callback in a GtkActionEntry.
+  because when using a detailed GAction name the name can become a bit hairy
+  (small tip / side note: to "git grep" it the `--fixed-strings` argument is
+  needed). The detailed GAction name would be the equivalent of the callback in
+  a GtkActionEntry.
+  Because currently, to avoid such hairy names, more GActions need to be
+  implemented, that can in turn call common functions.