source: npl/mediabox/lcdproc_edwin/src/docs/menustuff.txt

Allo...  (warning:  this was written as I thought it up :)

Ideas for implementing menus...

We've got a data structure called "Menu_Item", which has (for starters):

        Title           -- Text to display
        Child           -- Sub-Menu to recurse into, if item is picked
        Exec Function   -- Function to call if the item is picked

An item must not have both a child and an exec function.

The DoMenu(main_menu) handles all input and either calls ExecFunction,
if the picked item has one; or recurses into the Child menu.  The
ExecFunction returns a value to specify whether the menus should go
away, back up one level, or stay as-is.  Also, a menu title (label)
can be specified by giving neither a Child nor a Function.

The up/down arrows, blinking, scrolling, etc, are handled by DoMenu().

This gives us the functionality of a standard pull-down menu.
However, we need more functionality than that.  We need checkboxes,
sliders, and a way to move items up/down.

So...

The ExecFunction should take a parameter, telling whether the item was
simply picked, or if it had a +/- pressed on it.  This lets us change
a value from the menu.

We should also add another function to the MenuItem struct:

        Data Function   -- returns true, false, or 0-255.

This lets us find out if a checkbox should be checked, or where a
slider should be.  DoMenu() will figure out what widget it's dealing
with (if any), and adjust its display accordingly.

But we still can't move menu items up/down.


...


Perhaps...  This might work better:

        Title           -- Text
        Type            -- menu,  function, checkbox,  slider,   mover
        Data            -- Child, ExecFunc, CheckFunc, SlidFunc, ???

When an item is picked, DoMenu() decides what to do based on type.
--"Menus" will recurse into the "data", assuming it's a child menu.
--"Function"-type items will have their function called.  
--CheckBox-type items will have their function called with a "read"
  parameter to get an on/off signal, and called with a "set" signal when
  picked.
--Sliders will have the same "read" thing, and the "set" function will
  take a plus or minus parameter.
--The Movers will act like a label until picked, and then the +/- keys
  will both rearrange the menu, and send the item a signal of some sort
  to indicate what happened.  It'll act like a label again after the
  user presses Enter again.

The "Data" field will really be a "void *", which is C's "generic"
data type...

Anyway, this sort of thing would be declared this way:

========================================================================

Menu MainMenu = {
        "MENU",         NULL,           NULL,   // Title
        "Options",      MENU_TYPE,      (void *)OptionsMenu,
        "Kill LCDproc", FUNC_TYPE,      (void *)Shutdown_func,
        NULL,           NULL,           NULL,
};

Menu OptionsMenu = {
        "OPTIONS",      NULL,           NULL,   // Title
        "24-hour Time", CHEK_TYPE,      (void *)Time24_func,
        "Contrast...",  SLID_TYPE,      (void *)Contrast_func,
        NULL,           NULL,           NULL,
};


///////////////// Elsewhere, we declare these...

void Shutdown_func()
{
  // Do something here...
  return MENU_KILL;     // or MENU_CLOSE, or MENU_OK, or MENU_ERROR
}

int Time24_func(int input)
{
  if(input == READ) return status;
  if(input == SELECT) toggle_status();  // does something.
  return (status | MENU_OK);
        // The status is "or"-ed with the MENU value to let DoMenu()
        // know what to do after selecting the item.  (two return
        // values in one.  :)

        // Also, "MENU_OK" happens to be zero, so it doesn't matter
        // unless you want something else (like MENU_CLOSE)
}

int Contrast_func(int input)
{
  if(input == READ) return status;
  if(input == PLUS) increment_status(); // does something.
  if(input == MINUS) decrement_status();// does something.
  return (status | MENU_OK); 
}


========================================================================

The main reason I like this is that it completely separates the menu
definitions from the code which actually handles it.  We have *one*
function which does everything menu-related.

Also, we'd include a table of some sort to match names to functions,
so that the user can create their own menus with the functionality
already provided.  (including user-defined "functions", which will be
rather limited but still useful)