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:
  > generalise concept of 2D widgets:
    > some other way of specifying a widget's dimensions
    > divide layout widget into a sub-widget handler and a placement component, such that placement can use a rectangle, hexagon or whatever component
  > Menu widgets:
    > Need BoolContentWidget with name in menu
      > Special widget?
->  scripted widgets
->  decent rendering/theme system
->  events:
    ?>	Click events: WidgetManager separates out actions:
       >  left-click down:
	 >  starts drag monitor, visually depresses buttons
	   >  calls downClick, which can return codes to enable dragging, etc.
	 >  if mouse moved more than dragStartDistance from click-position and dragging-from-widget available, start drag mode:
	   >  visual feedback for dragging
	   >  releasing does drag action; releasing on start widget cancels action
	 >  otherwise, releasing does normal button effect (pass a eventClick)
	*>  consequence: button click/release & dragging more managed by WM; possibly less flexible for widgets
       >  dropContent(mouseClipboard): middle click paste action
       >  ...: open context menu
       >  eventScroll: scrolling event
      ->  Issue: release-click for menu buttons needs to be passed separately
    ->	Click/drag handling:
	->  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?
> Data:
  > remove "designs" concept from WidgetLoader:
    > have one design per file
    > to load multiple designs, have multiple WidgetLoaders in memory (so each just stores one set of data)
    > pass a reference to a WidgetLoader or whatever it's called to the WidgetManager
      > instead of class extension
      > allows easily swapping data sets


Content:
->  Per-content undo support?
>   Possible extra services:
    >   All content:
    >   Some content:
    	+>  Spellchecking
    	+>  Calculator
  > Context menus:
    > Context menu serves (editable?) content most directly under mouse cursor
    > plus content higher up widget tree?
    > "Drag" option to drag from, instead of widget itself?
> 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


Uses:
> A universal XML generator/editor from XSD files?