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/drag handling:
	->  on click:
	    ->	clicked widget recieves depress event
	    ->	create drag monitor, which records parent and optionally runs parent method on move (which can find the widget/drop-zone underneath)
	->  on release:
	    ->	method from either dragged or drop-zone widget called with reference to the other:
		->  perhaps function in dragged widget called, which is passed reference of widget underneath, and can call getDropZoneAncestor on this
	->  drag/drop-like possibilities:
	    ->	magnifier which is dragged from icon, creates a magnified window, and disappears on release
	    ->	colour-picker which is dragged from a widget and dropped to choose the colour under it
->  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
	->  Make only first widget draw a back
	    ->	extra parameter to pass in special cases
	    ?>	Transparency?
	    +>	Simple to implement
    >	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⁹
  > Context menus:
    > Context menu serves (editable?) content most directly under mouse cursor
    > plus content higher up widget tree?
> 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
> Widget content?

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).



From paper:
Text styles:
> use a few styles
  > number and purpose of each hard-coded?
    > titlebar, label, button, field, etc.
  > renderer or something maps a font (font file, size, style) to each style

GUI editor:
> Widgets are wrapped with/replaced by drag & drop widgets:
  > widgets can be dragged to another drop-zone widget
  > widgets can be dragged to a bin or scrap area
  > new widgets can be dragged from templates
  > widgets can be copied by holding Ctrl
  > widgets displaced by another are moved to the scrap area
> side bar/editor controls:
  > tree showing current widget structure
    > widgets can be moved (by dragging), restructured, etc. from here the same as from the WYSISYG view
  > new widget panel
    > for creating new single widgets
    > for creating new mini-trees from templates
  > scrap panel
    > widgets can be dragged here from WYSIWYG or tree views
    > widgets can even be edited here
    > widgets remaining on program/editor exit are lost?
  > properties panel
    > for setting widget options (initialisation data)
  > profile selection (section of config file to save to)
> for easy access to editor (power GUI dev mode)
  > include a theme selection box on the GUI
  > include a button to turn the editor on/off