Functions | |
void | glutAddMenuEntry (const char *label, int value) |
void | glutAddSubMenu (const char *label, int subMenuID) |
void | glutAttachMenu (int button) |
void | glutChangeToMenuEntry (int item, const char *label, int value) |
void | glutChangeToSubMenu (int item, const char *label, int subMenuID) |
int | glutCreateMenu (void(*callback)(int value)) |
void | glutDestroyMenu (int menuID) |
void | glutDetachMenu (int button) |
int | glutGetMenu (void) |
void * | glutGetMenuData (void) |
void | glutRemoveMenuItem (int item) |
void | glutSetMenu (int menuID) |
void | glutSetMenuData (void *data) |
Actual action generally occurs when an integer-bound item is selected. The integer can be any integer of the application's choosing, provided that it fits into a variable of type int. Enumerated values, array indices, and OpenGL and OpenGLUT ids are common choices. The item selection is handed to a menu callback that you specify via glutCreateMenu(). (Each menu can have its own callback, or you can use one callback for all menus, or something inbetween, according to your application's needs snf your own preferences.)
The original GLUT documentation disclaimed GLUT menus as being an attempt at ``a full-featured user interface''. Certainly, the GLUT menus are limited, but they are functional. At present, they are the only officially supported mechanism for creating practical menus. (Using subwindows in your own application window is possible, but the possibility of having your menus occluded by other applications' windows is a bit irritating.)
The following comment appeared in at least three spots in the freeglut code. Here in OpenGLUT we consolidate it into this overview, which seems more appropriate and useful. It appears to be an analysis of how old GLUT worked on WIN32 (it certainly is very different from old GLUT on X11). Some of the freeglut, hence OpenGLUT, menu problems seem to arise from trying to emulate the WIN32 behavior.
Do not execute the application's mouse callback if a menu is hooked to this button. In that case an appropriate private call should be generated.
Near as I can tell, this is the menu behaviour:
|
Append an item to the current menu.
The new entry is added to the end of the menu.
|
|
Append a submenu to the current menu.
The submenu is added to the end of the menu.
|
|
Attach the current menu to the current window.
|
|
Replace a menu entry with an item.
|
|
Replace a menu entry with a submenu.
|
|
Create a new menu.
When the user makes a selection from this menu, callback is invoked with the parameter value, which comes from the (label, value) pair that is defined with glutAddMenuEntry().
|
|
Destroy a menu.
|
|
Detach menu from the current window.
|
|
Get the current menu ID. Returns the integer ID of the current menu.
|
|
Retrieve menu user data pointer. Retrieve a previously stored user data pointer from the current menu.
|
|
Remove a given menu item.
|
|
Set the current menu ID.
|
|
Store menu user data pointer.
|