diff codeDoc/todo.txt @ 74:cee261eba249

Minor tweaks.
author Diggory Hardy <diggory.hardy@gmail.com>
date Mon, 07 Jul 2008 15:54:47 +0100
parents f54ae4fc2b2f
children 25cb7420dc91
line wrap: on
line diff
--- a/codeDoc/todo.txt	Mon Jul 07 15:53:58 2008 +0100
+++ b/codeDoc/todo.txt	Mon Jul 07 15:54:47 2008 +0100
@@ -2,7 +2,7 @@
 License: GNU General Public License version 2 or later (see COPYING)
 
 
-* means done
+* means done:
 
 GUI:
 ->  Widgets:
@@ -14,3 +14,37 @@
     ->  lists from content lists
 ->  Content:
     ->  lists
+
+
++ shows current preference:
+
+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 resolting 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