OpenGLUT has inherited numerous elements of dubious merit. Some may not have been well designed in the first place. Some may have been as well designed as was plausible, but their context has changed. Some have been rendered obsolete or redundant. At least one or two were officially deprecated by Mark Kilgard in the old GLUT 3.6 documentation.
freeglut retained these for compatibility reasons, since freeglut was intended to be used as a drop-in replacement for old GLUT.
For OpenGLUT, we are agreed to remove (possibly replacing) features. These removals will happen sometime after OpenGLUT's first landmark stable release---nominally after we cut and release "1.0".
This proposal will provide a rough list, to be refined by the mailing list discussion. Features may be added or removed from the list in this proposal. Removed features will also be listed for reference, until such time as some better repository for historic issues is provided.
The list here is intended to list the features that should be deprecated, and to explain why they should be deprecated. Deprecation does not necessarily constitute loss of functionality. The deprecated feature might be redundant of something already in-hand. Or a replacement feature might be crafted before or after. In any case, being listed here is merely a first step in removal. The next step would be deprecation if there is consensus, to be followed by eventual removal.
Also, this is simply a proposal. The actual process of doing anything is separate. And before the process is engaged at all, the items must be discussed. A feature being listed here only means that at least one active developer wishes to remove the particular element as it stands and as it is described here. This proposal, like any other, does not represent a discussed or agreed upon consenus and so there may or may not be any work coming out of the items listed here.
One, some, all, or none of the listed items may be deprecated.
What we should not do is keep the same name for an object and redefine its behavior. glutCloseFunc(), for example, will either be retained just as it is, or removed---it will not have its definition altered incompatibly as a direct result of being mentioned here.
Follows is a proposed list of features to be deprecated.
- GLUT_INDEX This feature should be easy to support, and if an implementation is offered, may be implemented. However, it seems of little currency and no one is offering to implement it. (This may be worth implementing, however, if someone wants to do it.)
- glutMenuStateFunc() This feature is superceded by the more general and useful glutMenuStatusFunc().
- glutVisibilityFunc() Also superceded by another function (glutWindowStatusFunc()).
- Game mode. This feature was never documented by old GLUT. OpenGLUT received a partial implementation (also undocumented) from freeglut. The freeglut (and so OpenGLUT) version has always been fraught with bugs. On UNIX_X11 systems, it cannot work reliably---freeglut/OpenGLUT rely upon an unofficial hack to do it on XFree86 (and no other X server). On some XFree86 systems, the video card driver has bugs in setting the resolution and can have disasterous impact, rendering the video display unusable. On some systems (any X besides XFree86, and even XFree86 if a compile-time option is selected), the video mode may not change, though game mode will otherwise appear to "work". making it impossible for applications to know what subset of game mode features they have gained. Additionally, having to manually encode the request as a string, then having OpenGLUT decode the string, seems like a classic case of over-engineering.
Most, if not all, of the problems would go away if the numerous components of game mode were decoupled. With a separate function for each component---and total failure or total success being the only outcomes---programs could reliably ask for what they need. Each function could take perhaps one or two numeric parameters, rather than having to parse a string.
This present proposal does not seek to define how to redesign game mode. It is merely intended to present the case for why the current API is unworkable, and to list game mode as something that may be removed.
A functioning replacement design would be welcome.
- glutCloseFunc(), glutWMCloseFunc(), GLUT_ACTION_ON_CLOSE OpenGLUT inherited two mutually redundant callbacks and a somewhat thorny state-variable that freeglut added for allowing programs to handle their windows being closed. These features should be replaced by a simpler mechanism, such as is outlined in the Window Close API proposal
- glutMouseWheelFunc() This function was very poorly designed. In mid to late 2003, a then-freeglut developer (Richard Rauch) suggested some explicit mouse wheel support, and the first idea that came to mind was to just create a +1/-1 "tick" callback. Later investigation showed that wheels varied significantly in the size of "ticks", so that a "stroke" of the finger could be very different for the same user on two different mice. WIN32 also has a mechanism for reporting the size of a "tick" it seems. In spring of 2004, wheels with no tactile "ticks" at all were seen in stores (the tick resolution reported by those mice is unknown). Despite criticism, and a workable existing alternative, freeglut adopted glutMouseWheelFunc() as it stands today. A client application can get exactly the same functionality by allowing OpenGLUT to report the "wheel ticks" as pseudo buttons. It is suggested that the freeglut glutMouseWheelFunc() should be deprecated in favor of the traditional method, and a usable API be designed to address wheels. Better ideas were foreseen almost immediately.
Generated on Tue Oct 5 18:44:33 2004 for OpenGLUT by
doxygen 1.3.8
The OpenGLUT project is hosted by sourceforge.net.