some thoughts on menu stuff

1 files changed, 29 insertions, 0 deletions

diff --git a/DESIGN/menu-thoughts.txt b/DESIGN/menu-thoughts.txt
new file mode 100644
index 00000000..b94e9305
--- /dev/null
+++ b/DESIGN/menu-thoughts.txt
@@ -0,0 +1,29 @@
+Okay Soldiers, here's the plan:
+menu.c contains functions for handling a menu list. This may have to
+be turned into an array.
+The invalid bit denotes whether the menu must be rerendered. Normally,
+it is auto-managed by the menu.c functions.
+
+Each menu has a set of controller functions that handle behaviour:
+ show() - place a menu on screen
+          also, may rerender the menu if the invalid bit is set
+ hide() - hide a menu
+ mouseover() - called when the mouse moves over a new entry
+               may highlight new entry and display submenu
+ selected() - called when an item is clicked on
+              may execute, change config options?, perform action, or
+	      display submenu
+ update() - re-render the menu
+           
+When a menu is rerendered, the engine can place any information like
+(x,y) coordinates, appearances &c in the renderdata.
+
+To customize the behaviour of a menu, set the controller function
+pointers. Some ideas:
+ - we can have plugins for PipeMenus, FIFOMenus, ConfigMenus, Toolbar,
+ &c.
+ - a TimedUpdate menu (say for mp3 lists) could call update()
+ periodically.
+ - window lists/workspace menus need to be optimized somehow since
+ these change often, and modifying the list that often will be
+ crap. needs profiling.