The "unmanaged" demo with custom menu; experimental
The "unmanaged" demo with custom menu; experimental
This proposal seeks to define, and justify, client-controlled menu windows. An experimental implementation is currently provided in OpenGLUT, per the outline below. It is not formally endorsed, but application developers are encouraged to use it and provide feedback on its utility. See also the unmanaged demo. (So-called because the feature originally used a GLUT_UNMANAGED display mode flag to glutInitDisplaymode().)
The API limits one to pop-up windows, rather than pull-down windows. They can only contain text, of a single predefined font, in two predefined colors (plus a beveling box). The layout is strictly linear, with the positioning determiend by fixed logic in the OpenGLUT library---there is no option to open the menu such that the "current" choice, in a multiway selection, is near the mouse. Nor is there any facility to navigate menus via keyboard (a major feature that some have noted as lacking in GLUT/freeglut/OpenGLUT menus).
The freeglut implementation suffers from bugs that leave multiple menus hanging onscreen, and can make menu selection unnatural. E.g., if one holds down the menu button to bring up a menu, selects an item that has a sub-menu attached, and (still holding the mouse button down), drags over to the sub-menu, finally letting go over a sub-menu item, OpenGLUT fails to properly respond to the selection of the sub-menu item.
While the GLUT API is functional, and it is possible to use the implementation, there is no provision for clients to create their own menus to work around the limitations and bugs.
Menus stand out as anomalies. In old GLUT, this made more sense, since old GLUT didn't actually work very hard; apparently, old GLUT used system menus. freeglut works very hard for its menus, in contrast. freeglut menus are much more complex than a simple GUI slider, and are probably about as complex as a fairly usable file-requester. Yet the API provided is stilted and limiting, because old GLUT was aiming for simplicity.
These are not all mutually incompatible, of course. And unless the old style GLUT menus are removed altogether, OpenGLUT should try to eliminate bugs in the old GLUT menu API.
However, this proposal asserts that exposing the mechanism for controlling menu windows is more in line with the GLUT approach to GUI construction, and is also simple to attain with what we already have.
A menu window is a pop-up window that may be placed anywhere by the application. Although system resources may always preclude any attempted operation, menu windows more closely respect the programmer's requests (as much as is practical for OpenGLUT to ensure). Additionally, menu windows will have no title, borders, or other decoration or other controls. These two major concepts are linked: Without any user control over the window, the application must have sufficient control to present the windows.
Some features that may make menu windows easier to work with in practice, and hence are tentatively suggested, are:
The experimental implementation does not enforce the associated hiding/destruction of menu-windows when the parent goes away.
The current support is through one new function:
glutCreateMenuWindow(int parent, int x, int y, int w, int h)
The similarity to glutCreateSubWindow() should be apparent.
A menu window exists as a top-level window at this time. The coordinates are relative to the position of the parent window. It is contemplated to make one of two changes:
Unlike a subwindow, a menu window exists in the same space as the parent. (Alternatively, it could be pushed to the top-level space; that has some appeal, but could make coordinate translation a bit more tedious.)
The parent is the parent window to which keyboard input will cascade.
The x and y coordinates are relative to the parent, though they need not lie within the parent.
The w and h width and height values can be arbitrary positive values, up to whatever limits may be imposed by the window system.
If the parent is a top-level window (or if menu windows are always top-level), then the created menu window should respect the current display mode settings. (Alternative: Borrow from the parent?)
The generalization is to ``borderless'' windows. This seems to work well at first with the menu concept, but there are wrinkles in attempts to implement these as a single concept. Utility for the generalized borderless windows would include:
Some of these, e.g., menus, seem to be satisfactorily functional with the experimental implementation.