view 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 source

Copyright © 2007-2008 Diggory Hardy
License: GNU General Public License version 2 or later (see COPYING)


* means done:

GUI:
->  Widgets:
    ->  rethink how widgets are created and receive creation data, so that they don't have to be created by the Window
    ->* minimum size but expandable, auto-set
    ->* grid "layout" widgets
    ->  scripted widgets
    ->  decent rendering/theme system
    ->  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