#5 Run-time configuration controls.


Back in the days when freeglut was being actively
worked on, it was discussed whether we should add some
kind of config. file facility. At the time, it seemed
like a good thing: I had a use for it, the freeglut
project owner endorsed it, and I was prepared to do the
work for it. However, the freeglut project owner threw
out the raison d'etre (in my eyes) for doing the config
file support, so I felt it better to wait until there
was some evident need that was actually going to exist
in freeglut. That never happened.

For OpenGLEAN, one use for this would be to allow
runtime configuration of whether to allow video mode
changes, since a video mode change can be a pretty
hostile. Of course, this permission should be selective
as I would not normally want (on at least some machines)
something as paltry as the "One" demo to change the
video mode (unless I'm specifically testing with it),
but I might be willing to tolerate it in a game, even
though I know that (on some machines) the result may
be a messed up video mode, owing to XFree86 bugs or a
program crash before restoring the proper mode.

The scope of this is a bit unclear. freeglut may
someday include such a feature, as may OpenGLUT. So,
to allow them to use the same mechanism, there should
be a way to identify the affected library, as well as
the application. And, at that point, it's not far from
being a general configuration tool...

Although not directly a window system issue, this would
provide portability support as well. On UNIX, one
would naturally use *rc files, but on WIN32 one would
perhaps use .INI files (as someone proposed on the
freeglut list at one time) or perhaps the registry.

Obviously, we are not talking about forcing *rc files
on WIN32 users. Rather, *not* forcing them is the
point. Just as WIN32 is not obligated to have X calls
in order to support OpenGLEAN, so it would not be
obligated to have *rc files. On UNIX we'd use *rc
files, on WIN32, we'd use what was a natrual
counterpart. (On an Amiga, one might do it by modifying
the program's .info file, for example. I think that
Macs have a similar concept.)

If we did this, a tool for editing preferences would be

Nigel Stewart suggests setting WIN32 environment
variables via "Control Panel -> System" as the natural
WIN32 correspondant to *rc files.


  • Richard Rauch

    Richard Rauch - 2005-03-30
    • labels: --> Misc. System Interface
  • Richard Rauch

    Richard Rauch - 2005-07-15
    • summary: Configuration controls. --> Application configuration controls.
  • Richard Rauch

    Richard Rauch - 2005-08-12
    • summary: Application configuration controls. --> Run-time configuration controls.
  • Richard Rauch

    Richard Rauch - 2005-08-12

    Logged In: YES

    I'm presently leaning towards using environment variables
    for this, everywhere. Setting environment variables is a bit
    hokey in WIN32, and it sounds like a cumbersome approach for
    UNIX since the mechanism for setting your variables depends
    upon your shell.

    It also does not admit of a natural hierarchy, so adding
    tuples of the form (library, application, tag, value) will
    result in long environment variable lists. E.g.: (OpenGLEAN,
    gleanMech, videomode, permit) might be a tuple for letting
    the OpenGLEAN permit the application "gleanMech" (a
    hypothetical game) change the video mode. The environment
    variable binding for that would probably look like:


    (Note that colon (:), hash (#), dash (-), and dot (.) are
    all not practical choices for word separators---though the
    underscore (_) has problems since programmers are likely to
    use those in application names.)

    To resolve this variable, OpenGLEAN would need to know its
    own name ("OpenGLEAN"), the application name (extracted from
    info passed into glutInit()) and the specific tag
    ("videomode", here). The specific tag may be implicit---as
    in the case of the application trying to adjust the video
    mode and OpenGLEAN checking if the application is
    ppermited---or it may be explicitly queried by the

    A downfall of this is that the application may be able to
    rewrite the environment variables. This configuration
    information is envisionned explicitly as a way for the
    *USER* to bypass the application, so letting the app. rewrite
    the OpenGLEAN config for the application is dubious.

    Also, it would be nice if the application could work with
    entirely private (non-OpenGLEAN) config data through the same
    mechanism. In this case, the application *would* be
    justified in rewriting the config data, and env. vars. do not
    export very well between unrelated processes. So a
    filesystem approach has advantages.

    Still, it is portable. And it is powerful enough to permit
    us to encode arbitrary information.

    It needs more thought.


Log in to post a comment.