Mercurial > projects > mde
view codeDoc/todo.txt @ 80:ea58f277f487
Gui reorganization and changes; partial implementation of floating widgets.
Moved contents of mde/gui/WidgetData.d elsewhere; new gui/WidgetDataSet.d and gui/types.d modules.
Changes to widget/createWidget.d
Partially implemented FloatingAreaWidget to provide an area for floating "window" widgets.
New DebugWidget and some uses of it (e.g. bad widget data).
Decoupled OptionChanges from Options.
author | Diggory Hardy <diggory.hardy@gmail.com> |
---|---|
date | Thu, 07 Aug 2008 11:25:27 +0100 |
parents | 25cb7420dc91 |
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