On Sat, Apr 30, 2011 at 12:50 PM, L Corbijn
<aspergesoepje@gmail.com> wrote:
Hi everyone,
I was wondering if anyone is working on improving the OpenGL package.
Yes. Alexander Göransson is doing a google summer of code project[1] with that specific goal. I'll be mentoring him. I've asked him to post his proposal to the list but I think he's a bit busy with his uni courses at the moment. Hopefully soon.
As the git repository [1] on github looks rather quiet,
The one you linked to is my personal branch. In general, I think you want this one:
I created the haskell-opengl organization on github specifically for managing the haskell opengl repositories. I think that StateVar, tensor, and possibly some other repos are missing still. I've been adding things lazily.
I've been kind of busy in my work/personal life lately so I haven't done much yet other than getting things up on github. I would like to do a release soon with some of the old patches that are floating around. Just performance fixes mostly. Then start looking at some of the more experimental stuff. I've created issues on github. Feel free to assign them to yourself or send me pull requests if you've been working on that stuff.
beside my (Laar, not my real name) casual editing. In that process of adding extra functions to improve the library to some higher version of OpenGL I ran into some structural inconveniences. But as I'm not that experienced with Haskell nor with collaborating in open source projects.
No worries. I would recommend reading, "Producing Open Source Software" by Karl Fogel, available online for free[2].
The major problem in my opinion is the boat load of deprecated functions and objects that make finding and having an overview of the code rather difficult. This is not helped by the fact that there are a lot of files that could be marked as deprecated. Therefore I think that something more serious should be done than only adding deprecated pragma's as Jason Dagit suggests in [2]. I think it should improve the overview of the code if all deprecated functions/code/etc. are move to a different namespace, say ...OpenGL.GL.Deprecated. This would help a lot as with coding new stuff the files would be quite a bit smaller as you wouldn't see the deprecated stuff. Though this will probably be quite a hard break with older code. Though quite a lot of code to refactor I think it would lead to a better structured project that is easier to maintain.
Thanks for the feedback. I'll think about it. I don't personally see the current code layout as an issue but I also don't want the code to be unnecessarily messy. Changing the high level module names, the ones people import, is problematic but I assume that at the end of the summer we'll be able to release Alexander's work as OpenGL 3.0 and we'll just warn people ahead of time that it's going to be a big compatibility breaker compared to OpenGL 2.4. That means we need to release any bug fixes we make along the way in the current 2.4.x series or else suffer the wrath of people who use the current API.
Furthermore in it's current state importing ...OpenGL.GL does import everything, whether it's deprecated, usefull or even only usable for higher versions of OpenGL-contexts than you use. Although the exported functions/Types wouldn't lead to clashes it would be nice to have modules that only export the stuff that is usable for a certain OpenGL-context (e.g. importing ...Core31 or ...Core31Compatibility). This would lead to a compile error when using unsupported functions, which is a lot more pleasant than having to debug why code doesn't work (talking from experience).
Could you give an example where you needed to debug something? I don't think I understand what you're saying. I will say, I find OpenGLRaw much easier to use as the names and types match the OpenGL API really well. It's a bit harder for beginners though as it requires more familiarity with the FFI.
And if the future brings better auto-complete for Haskell it might lead to better suggestions (all the unused stuff out).
You might try leksah[3] or eclipsefp[4] if you want wizzbang IDE style features. I get by with just emacs/vim plus find/grep/ack, but I might be a bit old school. Hoogle integration in my editor would be pretty nice though.
Jason