view codeDoc/todo.txt @ 75:25cb7420dc91

A massive overhaul/rewrite for the gui's data management and setup code. Currently much that was working is broken. imde's classes are created in a static this instead of mde's main. gl setup code moved from gl/basic.d to gl/draw.d mergetag.DefaultData: now HIGH_LOW priority instead of LOW_HIGH. Reduced type list to only used types; small fix for indent function. setup.paths: new NoFileException thrown instead of MTFileIOException
author Diggory Hardy <diggory.hardy@gmail.com>
date Mon, 28 Jul 2008 18:17:48 +0100
parents cee261eba249
children b525ff28774b
line wrap: on
line source

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


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


+ 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 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