diff codeDoc/ideas.txt @ 149:1125ba603af6

Some ideas for content service menus.
author Diggory Hardy <diggory.hardy@gmail.com>
date Sat, 14 Mar 2009 11:05:51 +0100
parents 9f035cd139c6
children e785e98d3b78
line wrap: on
line diff
--- a/codeDoc/ideas.txt	Sat Mar 14 11:05:31 2009 +0100
+++ b/codeDoc/ideas.txt	Sat Mar 14 11:05:51 2009 +0100
@@ -28,10 +28,41 @@
             ->	may require moving through a lot of widgets
             ->	with complicated substructures, may not be very intuitive
 	->  limit to popup menus?
-    ->  these keyboard events only passed if activated by code outside the WidgetManager and no text input callback is active?
+    ->  these keyboard events only passed if activated by code outside the WidgetManager and no text input callback is active
 
 Content:
 ->  Per-content undo support?
-
+>   Services:
+    >   All content:
+    	+>  Clipboard
+    >   Some content:
+    	+>  Spellchecking
+    	+>  Calculator
+    -2> Fixed list of services working on IContent/Content:
+        >   Clipboard - can't store Content (callbacks)
+            ->  needs to check content type
+            >   unless stored as char[] which all content can take
+            	->  extra conversions (minor)
+    	->  Need to check type of content for specific services
+    +1> List for each type of content:
+    	+>  can use a static list widget for each type
+    	->  clipboard is type specific; need to decide when to convert, etc.
+            +>  enables better copying; e.g. from double 3.5e9 to int 4×10⁹
+> Non-static content manager
+  > Separate managers for options, GUI symbols, data fields, passwords(?)
+    > Optional saving/loading
+    > Possibly different translation sources
+      > manager can take an optional Translator interface/super class, using it to translate strings if provided
+> Lists
+  > filtering uses
+    > filter context menu services to those relevant
+    > user-filters on, e.g., options
+  > filtering implementations (list widget)
+    > keep all sub-widgets, but hide some cells
+      > takes advantage of fact that actual elts don't change
+    > rebuild list
+      -> more work, recreating sub-widgets
+  > dynamic lists (add/remove elts)
+    > have to rebuild lists
 
 Extend content with a validator function/delegate, specific to each class, which takes the new value and returns it or a corrected version of it. Not so good to do it generally from Content, since setting a new value via usual method will re-trigger validator and callbacks (e.g. bad validator could cause infinite loop).