It may be useful to incorporate the additional glutCreate<type>Window() functions defined by the other proposals as well, for windows that have significant functional differences. This would be comparable to glutCreateSubWindow(). However, there are several additional window attributes that are worth making available to users, so this proposal is meanigful regardless of adoption of the other proposed API functions.
int glutInitWindowStyle(unsigned int style)This function is similar to glutInitDisplayMode, except that glutInitDisplayMode only defines features of the OpenGL rendering surface. glutInitWindowStyle defines traits that related to window manager interactions, and not the rendering surface. A few of these are experimental additions to glutInitDisplayMode, but should be handled here instead.
Examples of flags that could be supported:
Return value: There are a few options here. It could return void, as does glutInitDisplayMode. A better choice may be a boolean return, stating whether the requested mode is possible. Another possibility is returning a style value with the incompatible option bits set. In the case of multiple possible but incompatible options being selected, all bits would be set.
One use of transparent input-only windows is to monitor Widget areas without having to create multiple rendering surfaces, which may help performance and code simplicity. It may also be useful to supporet non-rectangular transparent windows to function similar to HTTP AREA definitions. For example, see MS-Windows Window Regions (HRGN type). This may be considered a bit excessive for OpenGLUT, but may be worth supporting if it can be done without producing too much code bloat.
There are also several non-boolean window style options worth supporting that require more than a flag, such as an allowable resizing aspect range. These could be handled via an extensible, parsed string:
glutInitWindowStyleString(char *style);
Window options in the category are open for discussion.