OpenGLUT Documentation
Introduction | Documentation | Examples | Proposals | Authors | Copying | Todo | Bugs | Links

OpenGLUT Init Window Style Proposal

Note:
This is a proposal for the purpose of discussion and discussion. This API is not currently implemented in OpenGLUT.

Motivation

It is clear that GLUT has insufficient support for Window styles and Window Manager interactions. Some experimental window options have been added to the glutInitDisplayMode function, but the GLUT API only uses that function for features related to selection of a desired graphics rendering surface. The Window Style options focus on everything but the rendering surface (except perhaps the shape of the rendering surface for non-rectangular windows).

Description

This proposal seeks to define window options related to interactions with window managers, and combines the intentions of the Borderless Window (OpenGLUT Borderless Window Proposal), Shaped Window (OpenGLUT Shaped Window Proposal) and the Menu Window proposal (propapimenuwindow).

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.

API function

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.

Associated glutGets

GLUT_WINDOW_STYLE_POSSIBLE - TRUE if the current window style is possible. Note: There may be some complications where the validity depends on, for example, whether one creates a top-level or sub window.



OpenGLUT Development @ Sourceforge
Homepage | Summary | Files | CVS | Forums | Lists | Bugs | RFE

Generated on Sat Feb 5 01:47:28 2005 for OpenGLUT by doxygen 1.3.9.1
The OpenGLUT project is hosted by sourceforge.net.