[openglean-devel]Tracking OpenGLUT.

[Richard R. <sf...@ol...>]

OpenGLEAN continues to track developments on both freeglut and OpenGLUT.

The latest OpenGLUT development seems to be a push towards deleting more
and more window-system events from the queue and calling the client
callback with a summary.

As with the original OpenGLUT notion of doing this just for mouse motion
events, there is no current indication of any value to this feature.
OpenGLEAN is generally informed by the philosophy of giving people rope
to hang themselves with, if it can also be used for other purposes.  It
is not clear that summarizing resize events is in any way harmful, but
no one has proposed any way in which it is helpful, either---and it
complicates the event processing.

OpenGLEAN remains committed to providing useful features and enhancements,
but these latest trends from OpenGLUT do not seem to be useful.  See the
freeglut discussion (and the even earlier initial OpenGLEAN reaction to
the mouse-motion summarizing).


Re. the OpenGLUT hack of using the tiny 8x13 fixed width font,
instead of Helvetica, for menus: Were OpenGLEAN planning to retain
the menus, certainly 8x13 is not the right choice, as it is visually
unpleasant.  Old GLUT used a nicer italicized Helvetica, I believe
(well, the system fonts on X generally did); the UNIX_X11 build of
current freeglut, older OpenGLUT, and all versions (to date) of
OpenGLEAN used an upright Helvetica, which was about as close, and
nice, as one can get within the limited GLUT fonts.  Also, the 8x13
font is very small.  In all likelihood no change at all will be
made to the OpenGLEAN fonts used for menus prior to the menus being
excised to a separate library or left to the client's responsibility.
But certainly not to a uniform choice of the 8x13 font.  OpenGLEAN
is concerned about legibility and aesthetics issues, which the 8x13
font undermines.


A couple of very minor changes from OpenGLUT have been adopted, but
basically the OpenGLUT changes since the fork do not appear to be in
line with OpenGLEAN's goals of producing a lean, flexible, simple,
flexible API nor with the sound software design principles of keeping
the software as simple as possible (but no simpler, right?).


-- 
  "I probably don't know what I'm talking about."  http://www.olib.org/~rkr/