Following up on the thread, "freeglut API from a new user's perspective",
Paolo: I looked back into the archives but missed your posting on celui. Sorry.
Andreas: Correct. My original idea was not to rewrite freeglut to be OO, but to
>add some overloaded C++ friendly calls to its interface,...
Your characterization of a wrapper is the same or similar. We are thinking about the same thing.
I have written a window class, intermediate-level classes such as drawAxis, and classes to perform several of the OpenGL drawing primitives. With them I can set up windows, populate them with drawn objects, and redraw them in C++. RGB colors, fonts, and strings are handled--albeit in a fairly messy fashion because I'm new at this. Although the code is C++, few OO features are included at this point.
I would rather work on my data than program drawing primitives in C++. But I failed to discover a good open-source, platform-interchangeable screen-drawing API that was lean enough to rely on for real time scientific data collection. (Matlab and similar high-level apps with hooks almost certainly involve too much overhead.) So here I am. freeglut is wonderful because it frees me from having to learn how to open windows, etc. on my OS. But it would be more wonderful if standardized open source code were available so that users like me didn't have to get down to the level of global callback addresses, arbitrary font sizing, and so on.
From: steve <sjbaker1@ai...> - 2006-11-27 03:18:46
My question is only "Why?"
Why do this? GLUT is a pretty terrible API - even wrapping
it in C++ isn't going to help that. We only need freeglut
to support existing applications and (especially) to be a
lingua franca for tiny demo's and bug reports and to provide
support for the example programs in the RedBook.
If your work is going to be incompatible anyway - why not just
start afresh and do something truly great without shackling
yourself to GLUT's little weirdnesses.
Think carefully about what this libraries scope SHOULD be.
Should it really include menues? (I don't think so) Should
it render fonts? (maybe, maybe not)
Make a base class for a rendering surface - spin off derived
classes for FBO's and windows.
Dump the the bad parts - *steal* code from the good parts -
but do it right.
But please don't try to make it anything like GLUT - this
old dog needs to die.