--- a/codeDoc/todo.txt	Mon Sep 29 18:27:17 2008 +0100
+++ b/codeDoc/todo.txt	Wed Oct 01 23:37:51 2008 +0100
@@ -4,43 +4,22 @@
 
 GUI:
 ->  Widgets:
-    ->  rethink how widgets are created and receive creation data, so that they don't have to be created by the Window
-    ->  scripted widgets
-    ->  decent rendering/theme system
-    ->  lists from content lists
-->  Content:
-    ->  lists
+->  rethink how widgets are created and receive creation data, so that they don't have to be created by the Window
+->  scripted widgets
+->  decent rendering/theme system
+->  lists from content lists
 
 
-+ shows current preference:
+Scratchpad area for ideas:
+
 
 Redesign:
-->  requirements
-    ->  widgets can receive int and string data types
 ->  possibilities
-    ->  per-widget merging (i.e. separate tag(s) for each widget's data)?
-        ->  if a widget with sub-widgets is defined in a base file, but redesigned in a derived file, any unused widgets with data resulting are not created
-        ->  if design changes in a base file, while the old design was modified in a derived file, will the result be sane?
-        ->  if a locally modified gui is updated upstream (so the base files change), should:
-            ->  the local modifications persist?
-            ->  the local modifications be lost?
-            ->  the widgets be merged?
-            	->  potentially gives the best of both worlds
-            	->  should original widgets used as sub-widgets of modified widgets:
-                    ->  use original data (from base file), so they can be updated?
-                    ->  have data copied, also impacting unmodified portions of window using same widget?
-                    ->  have data copied under a new ID?
-            ->  the user be asked?
-            	->  requires copy of old data...
-    +>  widget data per-gui instead of per-window?
-    	->  identical sub-widget could be used in multiple windows more easily, when data file is hand edited
-    	->  in-gui editor will probably copy data under a new ID anyway
-    	+>  Maybe change to:
-            ->  One section per version, containing widget data
-            	->  can inherit from other sections
-            ->  Which section (version of gui design) to use saved in header
-            ->  Either/or:
-            	->  Windows defined in header by primary widget
-            	+>  Windows become ordinary sub-widgets or some parent widget, gui becomes a parent widget
-    +>  widget data no longer has "construction" and "mutable" variations
-    	+>  widgets know their IDs and update their data whenever necessary, via the gui, into a new data set, which is saved upon exit
\ No newline at end of file
+    ->  How widgets get their sub-widgets:
+        ->  (current) Ask manager to create widget from manager's data with ID from widget's data.
+            ->  seems to work well; allows widgets some control over creation of children
+            ->  now extended to support instancing & passing content; seems to fulfill requirements
+        ->  (alternate) Pass widget a list of pointers to all sub-widgets
+            ->  manager creates all static (from data files) widets
+            ->  other widgets can create dynamic widgets as or to pass to sub-widgets
+            ->  widget data needs a portion which is explicitly IDs for subwidgets, or data needs reforming into a tree