I noticed that the last release of GLUT is shortsightedly limited to 3 mouse buttons and 4 joystick buttons. Why not allow N buttons on a mouse in the API, so that when the appropriate drivers are created, the functionality may be implemented without requiring an API change.
I suggested this in the "suggestions for upcoming OpenGL features" but was told to suggest this here.
Rob Stoddard
But it won't do any good as GLUT is not being updated or maintained.
I have tried to talk with NateR and/or MarkK about releasing some updated sources and builds, to no avail. Humph!
In the meantime, the way round it as I see it is for those who make changes is to send out the full source, with their changes as patch files, and then let users patch their source codes and re-build as necessary!
Sigh .......
Or, users go for a different/newer package, and I am sure there are a few who pop in here who would recommend something! ;-)
Rob.
I modified the original source, but only for the mousewheel. Its not hard, thats for sure. Since GLUT is not being maintained/updated, maybe it would be possible to obtain the right (or rights) to maintain the source. I will look into it, but I really don't feel like maintaining GLUT all by myself.
I added in the glutCheckLoop() to split off the glutMainLoop() (modified version of the original hack by Steve Baker)
and also WMCloseFunc()
which allows you to register a callback (per window) to trap the close window message (or client message in X-Windows), to stop the application simply shutting down when a user closes the window!
Did you update the sources for both Windows and Unix?
Rob.
actually I havent because the support for mousewheel is sooo shaky, individual installs will have different button numbers for the mousewheel, usually 4 and 5 for up and down. When I coded mine, I decided I'd save on "buttonspace" by making the wheel one button, and use the up-transition as up, and the down transition as down. Mind you, this is just my little hack and I dont mind having something that runs on windows only at the moment. Mebbe we should all sit down and hum-haw about what should go where, and how we are going to support what in this ever changing world of mice.
But for now, do we have authorization to modify and release GLUT changes?
Nope.Originally posted by 147-2:
But for now, do we have authorization to modify and release GLUT changes?[/B]
Besides, it's time GLUT died. The library is a pile, IMHO. It's antiquated, unsupported, and buggy.
Regards,
Jim
Maybe so, but what do you propose as a replacement? GLUT is small, fairly easy to use and runs on just about anything. Plus there about a zillion example programs out there that use it.
Jim ... you are right. Can't release new stuff etc etc, and yes it's unsupported, a bit buggy, and I guess for a lot of people a bit of a pain to use in a pure C++ environment. [But let's not forget the Fortran people out there who use GLUT!]
The "replacement" cross-platform libs out there all do much the same as GLUT in various ways, and with varying levels of success re full cross platform, C++ conformance, and so on.
Ease of use is also another issue as well as lots of example OGL code out there based on it in order to run (heck even nVidia demos use it!).
The problem is that if GLUT had been supported, and used as much as it is now (back in them thar olde worlde days), it might have developed into a better package and even made a transmogrification into GLUT++ as well!
I have no simple answer.
Rob.
Well, I would say it is probably easier to fix what's broken on GLUT than it is to write a whole new lib. I for one am glad GLUT is not a C++ lib, even though I have programmed in C++ for 10 years or so, I shudder at the thought of using a C++ lib. There are a lot of ppl out there that try to create libraries for C++ and end up creating something thats unintuitive, and a real pain to use. Id rather stick to a C library. At least there I know what a function requires, and I can differentiate library functions from my program's functions, since my program is in C++, and the funcs are in structs/classes, and the lib's funcs are global.
Anyways, I would like to see GLUT grow into something useful, and having it be supported by one or two individuals is not going to accomplish that. There are a lot of programs and examples that use GLUT, plenty of authors who have written books on GLUT, etc. Why throw away all that good work because of a few problems?
How bout we see if we can do this. Im interested in putting in my two cents on such a project.
There are more than a few problems with GLUT. There are licensing issues, code issues, support issues, etc.. For example:Originally posted by 147-2:
Anyways, I would like to see GLUT grow into something useful, and having it be supported by one or two individuals is not going to accomplish that. There are a lot of programs and examples that use GLUT, plenty of authors who have written books on GLUT, etc. Why throw away all that good work because of a few problems?
How bout we see if we can do this. I'm interested in putting in my two cents on such a project.
1) the code base is an antique, it does not support (nor could it) the latest hardware out there.
2) the code base is generally a hack. Not maintainable, hard to debug, impossible to expand upon, impossible to interface.
3) the author has abandoned the project, hence there are no updates.
4) the author refuses to open source it, so no other authors can fix the many problems it has.
5) the source is, at best, unreliable on 90% of the world's desktops and has contributed to the perception that OpenGL is unstable.
Currently, there are not good cross platform replacements. If you really want to put effort into this type of a project, try working on some of the modern replacements to improve their functionality, and support. That, would be a better solution. IMHO.
Regards,
Jim
Posting Permissions
