Mercurial > projects > mde
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