As someone having worked on and off as a hobbyist with OpenGL but now getting deeper into it due to development for non-Windows platforms I have to agree with some of the sentiments. That doesn’t mean I agree with the general attitude of the OP as most what he want seems to be targetted at the wrong people.
Here’s a few comments:
I would like to humbly ask you to discuss this within the Khronos community to find capable people to finally build us (newbies, Starters, etc.) a unified OpenGL IDE Suite.
Now in the year 2015, there is a huge bunch of additional libraries of various origin but no common srategy.
No, we do not need an IDE. OpenGL is just a programming API, after all, it should not require special tools to develop software for. As long as it can be used within existing development toolchains it is fine.
What i would like to see is Khronos is taken over Guidance and Parentship over these various libraries: glut, glew, glfw, glu, gl. like the Apache is doing with its Foundation and / Incubator.
No, sorry, that’s not how things work, because these have very different goals. One central maintainer wouldn’t help here, because some of these have to be tightly integrated with the underlying platform (gl), or need to be programmed platform specifically (glut, glfw) or are mostly obsolete (glu).
I agree that some more unified means of getting extension entry points is needed, but this shouldn’t be GLEW which is probably the worst of the existing tools if you want to target more modern OpenGL (I had my fair share of issues with GLEW’s ‘let’s make everything public’ method and switched to an extension manager that allows me to explicitly specify which GL version and which extensions I want to enable, so that accidental use of obsolete features triggers a compile error, not some hour-long bug hunt.
There are good tools for that, unfortunately they are not promoted well, so people always revert to the better known but inferior ones.
Get the Graphics card venders into your boat as well.
I don’t think they’ll go any further as they are already, i.e. developing drivers for their hardware. Which should be ok.
So the upcomming IDE should be ONE package and must include in its Installer:
As I said above: No! Windows users use different versions of Visual Studio, Apple users use XCode, Linux users may use Code::Blocks but often stick to simple makefiles. You’d alienate all these people by forcing a custom IDE that will most likely be inferior to all the present options.
- Check the newest gl libraries and include them correctly
That’s never going to work. There’s several OpenGL versions so more control is needed, including some THINKING by the developer. You have to make up first which versions of OpenGL to target before you can include the proper libraries/headers.
- Include and configure the GCC, gcc+ for a start
Outside the Linux world nobody uses GCC anymore so how would that help?
- Compare them with the Repository, Khronos will have for these gl libraries
- Make a Sanity check of found gl libraries, missing ones, etc. about version, location, vendor
- Include Language Support for the big ones: C, C++, Java, Pascal, etc.
That’s not how software development works. You absolutely do not want a third party to decide on its own to change the headers and libraries a project uses. NEVER!!!
About language support, it’s not about supporting languages, but development tools. But last time I checked most of these already come with GL support, as long as the platform supports GL.
- Include ALL Demos of the Redbook
- Include ALL Demos of the current OpenGL Programming Guide
- Make Ready to Run OpenGL Demos to test the installation
- Create CodeHighlighting (Like Jogl) in that IDE and make clickable references to the explanation of each gl command.
- Create OpenGL Projects, GLSL Projects, WEbGL Projects etc in that IDE
Ok, here we get to the stuff where things really start to break down.
The most frustrating issue with OpenGL in general is a profound lack of good documentation. Just compare to the extensive docs that come with DirectX and it screams ‘Trouble!’
It can become a chore to find good explanations about how to do stuff, all we have is the extremely verbose and mostly useless specifications, it even gets worse for extensions: The way they are ‘written against’ a base spec makes them a nightmare to read and comprehend.
What developers really need is not a wall of words about technical minutiae but some understandable explanation of what this does and how it is to be used. Again: Just look at the DirectX docs, they often helped me understand things about OpenGL when the GL docs were too obtuse about it. In this regard: Shame on you, Khronos!
Please remove all these obsticles from the Beginners (FINDING the correct Gl libraries for their OS, find an IDE which doesn’t suck, setup and configure the ide to run opengl code without studying astrophysics or the klingon language, etc.)
Again, its 2015, now we have an upcomming OpenGL 4.5 but we still don’t have a proper Set of OpenGL Software Development Suites. Imagine the Boost of the entire Opengl community, when newbies can run the installer and can - out of the box - run their first openGl demo with a current OpenGL Version.
That’s clearly not the problems that need to be solved. You have to do some work yourself.
Even a newbie needs to be familiar with the development tools available for the platform they want to target, that’s clearly not the business of some API designers.
To summarize, I think there’s two problem areas with OpenGL:
- stop promoting bad extension loaders, instead pick one that does the job right and allows to create configurable headers with the precise content a project needs - and then make that one the ‘official’ one.
- take the time to write some actual developer friendly (and FREE!) documentation. Not some heavily overpriced books that do a piss-poor job at introducing developers to OpenGL. I think this has been one of the biggest reasons why OpenGL tanked so badly against Direct3D on Windows which always came with some extensive and well written documentation. It’s not a difficult decision to choose against GL in such a case. But now with other platforms like mobile phones and MacOS X gaining more popularity this easy way out is getting harder and the frustration level of developers is increasing. Also Provide an extensive suite of examples, covering all important aspects of OpenGL with that documentation.
I really don’t think more is needed.
Haha! Yes, right, I have been reading through some of Agent D’s posts and this boneheaded adding of ® sure does make them look stupid on sight, if not worse.