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?
Originally posted by 147-2:
But for now, do we have authorization to modify and release GLUT changes?[/b]
Nope.
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.
Originally posted by 147-2:
[b]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.[/b]
There are more than a few problems with GLUT. There are licensing issues, code issues, support issues, etc… For example:
the code base is an antique, it does not support (nor could it) the latest hardware out there.
the code base is generally a hack. Not maintainable, hard to debug, impossible to expand upon, impossible to interface.
the author has abandoned the project, hence there are no updates.
the author refuses to open source it, so no other authors can fix the many problems it has.
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
Originally posted by ldglite:
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.
Pick one.
Regards,
Jim
>http://www.mathies.com/glfaq/
>Pick one.
If you look at the list of windowing application frameworks, there really aren’t all that many choices. Only SDL covers as many platforms as GLUT, so I guess that’s the way to go. Too bad nobody ever put together a GLUT emulator on SDL (SLUT?). That might make the transition a bit less painful. I wonder if some of the freeglut code could be pasted onto an SDL backend…
>Only SDL covers as many platforms as GLUT,
>so I guess that’s the way to go.
Unfortunately SDL is not quite as portable as one would think. Yes, it says: Windows, Linux, QNX, MacOS etc etc. But, have you ever noticed that the SDL apps/demos/games at the SDL page have “compability ratings”? In fact, if you probe the SDL source, you’ll find lots of strange things, like unimplemented functions on some platforms - beceause it “can’t be done” (or is very difficult to do/emulate). Which, sadly, is not mentioned in the docs (I even hear people say “use the SDL source for a manual”).
Don’t get me wrong. SDL is a great toolkit, but it (currently) has some flaws (especially regarding portability) that you should be aware of. I personally think that an API redesign is necessary to get SDL robust enough for the portability that it currently claims to have.
Anyway, all toolkits have pros and cons. None of them is really “there” yet (lack of maintinance, lack of portability, lack of language/compiler support, lack of robustness, lack of documentation, lack of features, etc).
It is not very likely that any single toolkit will become the GLUT replacement in the future. So my advice is to check out all the toolkits in the mentioned FAQ, and pick the one that fits your needs the best.
Hrm, was I too verbose again? 
Originally posted by ldglite:
GLUT is small
Compared to what? The library source is > 1.4 MB (win32+x11), and the Windows DLL is > 150 KB.
GLFW (being a minimalist OpenGL toolkit): source 325 KB (win32+x11), Windows DLL 28 KB
Of course, SDL is a bit bigger (almost 4 MB for the soruce and > 200 KB for the DLL), but then again, it’s not a pure OpenGL toolkit.
Glut is small compared to MFC, QT, GTK, VB, OpenGL/Mesa, and for that
matter my executable (~500K stripped). These days, a 200K static
library linked the the application is not really a problem for me.
GLFW might be nice and small, but I require MAC support so it’s useless
for me, no matter how small it is.
By the way, if none of the listed windowing toolkits will ever be able to
replace GLUT, why bother. Why not work on freeglut? What’s so bad about
the GLUT API that everyone feels the need to come up with their own. If
the GLUT code turns your stomach, fine, replace it. But is the API all
that bad? I don’t think so. In fact, it seems pretty darn similar to the
APIs in all these newer (but somewhat lacking) toolkits. All of them
could have been done using the GLUT API with a few modern tweaks that
mirror the functionality of the GLUT patches listed on the toolkit FAQ.
GLFW might be nice and small, but I require MAC support so it’s useless
for me, no matter how small it is.
I would also like to see a Mac port of GLFW, but until someone gives me a Mac or decides to do the port himself, it won’t happen (sadly). I think a MacOS X port shuldn’t be hard to do (a guy did a rough draft with the basics and could compile & run most GLFW demos). A nice thing for instance is that MacOS X has pthread, so you can basically rip the X11/Unix code for the threading part of GLFW 
By the way, if none of the listed windowing toolkits will ever be able to
replace GLUT, why bother.
With “replace”, I mean all aspects of GLUT, including legacy code compability etc (which is impossible without doing a GLUT API implementation - just as freeglut does). Most toolkits are able to replace (and surpass) GLUT for certain/most tasks, but that requires that the programmers start from scratch, and do not rely on GLUT (for instance, you can’t use GLUI with any toolkit other than GLUT).
Why not work on freeglut?
Honestly, if I knew about freeglut before I started coding GLFW, GLFW would probably not exist today. On the other hand, I know many people who are very happy that GLFW does exist.
What’s so bad about the GLUT API that everyone feels the need to come up with their own. If the GLUT code turns your stomach, fine, replace it. But is the API all that bad? I don’t think so. In fact, it seems pretty darn similar to the APIs in all these newer (but somewhat lacking) toolkits. All of them could have been done using the GLUT API with a few modern tweaks that mirror the functionality of the GLUT patches listed on the toolkit FAQ.
I think that in order to bring GLUT up to speed, you would have to either break compability or introduce much redundant functionality (have both old and new versions of the same basic functionality), which, in the end, is not much different from a completely new API.
The toolkits may look the same, but it’s the fine points that make a difference. I am thinking about things like:
You can’t bring these modifications to GLUT easily without messing up or bloating the API. Well, prove me wrong, but I don’t think GLUT would be much easier to use, meaning that an alternative, clean cut, toolkit may be worth considering.
I think you’re taking the wrong approach. Think about starting from a
smaller, cleaner, lower level cross platform toolkit (like say glfw)
that already has those hooks. Then see what it would take to provide
a GLUT API layer on top of it so people could still use GLUI and GLOW
and all the other code that’s already layered on top of GLUT. If you
do it right, it should be easy to add a GLUT-like function call for
advanced keyboard access and a high resolution timer. And there’s no
reason why you couldn’t add other input extensions to the GLUT API for
your super joystick, or power glove, or whatever.
Don’t forget how many users Microsoft has captured with their embrace
and extend policy. OpenGL needs to leverage the success of GLUT if
it’s going to survive. Please take a look at the freeglut source and
at least consider what it would take to layer it on top of something
smaller and more modern before abandoning all the good things that
have been done with GLUT.
Well, it simply comes to this. There are implementations of GLUT out there, but what needs to be renewed is the specification. There are plenty of books and tutorials out there for GLUT, if it isn’t supported then we lose all of that good work.
What needs updating is the GLUT API, not the code. Well, the code does need updating, but if we modernize the API, and then the code to follow suit, then we have a workable standard. To throw away GLUT because it isnt modern or has a few problems is to throw away a lot of ppl’s work, including books, demo programs, some of the most used tutorials, etc.
Originally posted by 147-2:
what needs to be renewed is the specification.
Exactly my point. You need to take GLUT in new directions and change the API. What I am saying is not that you should scrap GLUT, but it lacks some things in its design. Alternate toolkits are there to fill in those gaps, not by saying “GLUT sucks”, but “GLUT is good for [this], but this toolkit is better suited for [that]”.
I see no point in making GLUT cover the entire range of features offered by other toolkits, such as FLTK, GLFW, CPW etc. It would make GLUT HUUUUGE and incomprehensive (to say the least).
Hi,
Well, as I can see from reading this, th emain arg for using GLUT is to support the huge range of “legacy” apps, books, tutorials etc …
So, the real way to combat this is to provide a GLUT emulation layer to sit on top of a.n.other “better, better engineered, more robust, more extensible, free, etcetc” support package!
So, the question becomes …
Which, of the packages out there could host a GLUT emulation layer?
If there is one, there must be a number of people who could help write the layer. I would!
Of course, the underlying non-GLUT package API would still be available for use so the extra added support etc etc could be used either as full standalone “package-A”, or in tandem with the “GLUT” layer calls.
A tall order, but surely not impossible. Most of the packages have to provide the basic stuff anyway, and let’s face it, GLUT really is only providing the basic stuff, which is why people are “muttering”.
Any takers, packages and/or helpers?
Rob