OpenGLUT Borderless Window Proposal

Note:

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

This proposal defines a concept of windows that lack any kind of border or decoration. The term ``borderless'' has some precedence for this, though ``undecorated'' might be better.

It is currently implemented in OpenGLUT with a GLUT_BORDERLESS display mode flag. (See glutInitDisplaymode().)

Problem.

For some special-purpose windows, the border and decoration that a normal window has is unacceptable. If the window is offsceen or a subwindow, this is not a problem, as the borders are meaningless for the former and not applied for the second, in the GLUT family.

Menus use such windows. (See OpenGLUT Menu Window Proposal.) However, there are some problems to date with using menu windows for general windows, and vice versa. On the one hand, the windows presently used for menus have peculiar behavior for keyboard input (on X, some window managers will not give keyboard input to menu windows unless OpenGLUT forces the issue---which can violate the user's focus policy). Another problem is that menu windows do not respond well to virtual desktop paging. There is some hope that both can be addressed by using a parent window, which can act as a proxy for these events. This is outlined under the menu window proposal.

The contrary problem is that there is as yet no known universal way to acehive a borderless window without, at least on some window managers, doing what the menu windows do. It may be practical to identify the current window manager at run-time and choose an appropriate method. One OpenGLUT developer has described this as ``hacky'', and it is not clear that such a method would be acceptable, if it were the only method available. The menu window concept appears to be good enough to handle menus, and menus are highly desirable. Borderless windows are also highly desirable, but if they cannot be achieved in a uniform manner, it would neither be acceptable to remove the concept of menu windows nor to cause menu windows to become normal windows on some displays. (So, at least, is held by the author of this proposal.)

The Proposal.

For this reason, a concept of ``borderless windows'' is tentatively proposed. We hope to be able to merge the concept of borderless windows and menu windows back into one concept. Failing that, this proposal, coupled with that of ``menu windows'' provides some much-desired functionality and the two concepts can be evaluated separately. Even should they be mergable, the separate evaluation seems worthwhile, as menu windows may eventually be re-submerged under a slightly higher level menu management API, perhaps a straightforward extension of the API defined by the original GLUT.

In particular, it is proposed that a new symbol be defined: GLUT_BORDERLESS. This symbol will be a bit flag to pass to glutInitDisplayMode(). When a borderless window is requested, OpenGLUT will provide a window that is as much like a standard, top-level window as possible, and will also try to remove the borders and decorations, so that the only graphics created for the window will be a drawing space for the OpenGLUT application to draw on, using OpenGL.

This feature is currently implmented in an experimental form. In order to get reasonable behavior of keyboard input on some systems, it is necessary to redirect the input focus. The manner in which this is done may undermine input-focus policy on some systems. We are considering other mechanisms to support borderless windows.

Using Borderless Windows.

This is envisioned as potentially having the following uses, at least:

• Possibly a base for a menu system.
• Tooltips.
• Dockable widgets for other applications.
• Draggable icons that can move across the display, between windows. (With the vague hint at a shaped window extension, this could be especially desirable, from an aesthetic standpoint.)

This list may seem familiar, and that is hardly a coincidence. The potential uses are the same as for menu windows, if we can unify them.

The Difference From Menus

The difference is that menu windows have parents, which may help solve the deskop pager problems and the input problems. Additionally, as menus tend to pop up for brief periods and go away, the desktop paging issue may not be as significant as for normal windows that may be open for minutes or hours. Finally, some systems may have features to exploit the short-lived nature of pop-up windows such as menus; in particular, X provides a ``save behind'' flag to indicate that the X server should preserve the graphics that the pop-up window is covering, which may allow the obscured window(s) to avoid a gratuitous window refresh. Borderless windows, on the other hand, will be more expected to respect pagers, will not have parents, must handle input normally, and with their longer lives will not generally be able to aid the system with ``save behind'' options.

Additionally, menu windows ideally should be more or less immune to being resized, moved, or pushed behind normal windows. Borderless windows, on the other hand, are not so privileged, and should be subject to normal window operations.

The Experimental Implementation.

The current GLUT_BORDLERSS provides a rough experimental implemenation, but is mostly leveraging code that was was designed for menus.

In response to the original version of this proposal, the following changes are tentatively made to OpenGLUT:

1. Rename the GLUT_UNMANAGED flag to GLUT_BORDERLESS. (This has been done.)
2. Keep the old IsUnmanaged window state.
3. Add a new IsBorderless window state.
4. IsBorderless implies IsUnmanaged, but not vice versa.
5. In glutMainLoopEvent(), the input-focus handling should be sensitive to IsBorderless, not IsUnmanaged.
6. Add a glutCreateMenuWindow() interface as described in the menu window proposal. Menus are implicitly unmanaged, but not borderless.

The biggest semantic problem that this proposal has is that an unmanaged window is borderless. A better name may be needed than ``borderless'' (though ``undecorated'' has the same problems).

On the other hand, reversing the implication of the two types seems at first blush to make the support more complicated.

The intent was that the original experimental implementation of GLUT_UNMANAGED should be split in two. This will allow both features to be explored more comfortably.

Feedback

Feedback, comments or suggestions can be directed either to the mail list or discussion forum.




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.