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