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


Make a special "trace" logger which keeps the last 20, say, trace messages and only output them when asked to do so, which might happen when an exception is caught. It might output them via the normal mechanisms, but only when asked (and not all messages may be in the correct order: trace messages might be logged later than they were added to the list).

Use debug scope(failure) to output log messages in many places.


GUI:
->  Widgets:
->  scripted widgets
->  decent rendering/theme system
->  events:
    ->	Click events: widgets only receive clickEvent for left-button press, other button events handled alternatively from WidgetManager?
    ->	Click callbacks: replace with "drag callback" notifying widget of release position (and widget)?
	->  possibly better for drag-and drop support
->  Keyboard widget focus/selection:
    ->	a widget is highlighted
    ->	pressing an arrow key replaces widget with widget.nextInDirection (widget, direction)
	->  on non-parents, nextInDirection returns parent.nextInDirection (this, direction)
	->  on parent widgets, if widget is a child and not right against relevent edge,
            then tries to return next descendant in direction (only non-parent widgets are returned)
            else does same as non-parent widgets
        ->  some widgets may popup a menu when activated
        ->  caveats:
            ->  all widgets need a highlighted state to show focus
            ->	may require moving through a lot of widgets
            ->	with complicated substructures, may not be very intuitive
	->  limit to popup menus?
    ->  these keyboard events only passed if activated by code outside the WidgetManager and no text input callback is active
>   Drawing windows/popups (to draw a back):
    ->	Use the same renderer & manager:
	->  Make all widgets draw a back?
	    ->	bad for transparancy and performance
	->  Force first widget to draw a back
	    ->	extra parameter to pass in special cases
    >	Use a sub-renderer
	->  extra parameter to pass
	->  or some kind of lookup by mgr
	+>  enables nice transparancy
    +>	Use a sub-manager
	+>  holds a sub-renderer or something
	    +>  enables nice transparancy
	?>  integrates with popup support? will this work?
    >   each floating/popup widget has its own renderer (last two above)
	+>  combined rendering (to texture?) of each "layer" to enable nice transparancy
	>   lower performance?


Content:
->  Per-content undo support?
>   Services:
    >   All content:
    	+>  Clipboard
    >   Some content:
    	+>  Spellchecking
    	+>  Calculator
    -2> Fixed list of services working on IContent/Content:
        >   Clipboard - can't store Content (callbacks)
            ->  needs to check content type
            >   unless stored as char[] which all content can take
            	->  extra conversions (minor)
    	->  Need to check type of content for specific services
    +1> List for each type of content:
    	+>  can use a static list widget for each type
    	->  clipboard is type specific; need to decide when to convert, etc.
            +>  enables better copying; e.g. from double 3.5e9 to int 4×10⁹
> Non-static content manager
  > Separate managers for options, GUI symbols, data fields, passwords(?)
    > Optional saving/loading
    > Possibly different translation sources
      > manager can take an optional Translator interface/super class, using it to translate strings if provided
> Lists
  > filtering uses
    > filter context menu services to those relevant
    > user-filters on, e.g., options
  > filtering implementations (list widget)
    > keep all sub-widgets, but hide some cells
      > takes advantage of fact that actual elts don't change
    > rebuild list
      -> more work, recreating sub-widgets
  > dynamic lists (add/remove elts)
    > have to rebuild lists

Extend content with a validator function/delegate, specific to each class, which takes the new value and returns it or a corrected version of it. Not so good to do it generally from Content, since setting a new value via usual method will re-trigger validator and callbacks (e.g. bad validator could cause infinite loop).