Hi everyone,
HOpenGL hasn't really had any major update lately. Though I think there are
quite some things that can/should be done on the package. Therefore I've
made a list of task/ideas so people can decide what should(n't) be done.
Comments, ideas and remarks are welcome as I would like to know which of
these things you value and which are worthless so I (and others) can take it
into account when programming on the package. I've added a list of them
grouped in three categories, and after that there is a little more detail
about them.
General work (external API visible)
- Make the package OpenGL 4.2 compliant.
- Do something useful with the deprecation model
- Rework/implement support for matrices
- Add per OpenGL version export
Restructure the internals
- Rework marshalling
- Restructuring to get it more type-safe
- Restructure the module hierarchy
Policies
- Policy on extensions
- Policy on testing
- Policy on documentation
*General work*
*
Make the package OpenGL 4.2 compliant.*
The current package supports OpenGL 2.x as maximum. I've been doing some
work on 3.0 (which has the worst spec of all) and I think to be over 75%,
maybe even over 90% ready. But the package should, of course, be supporting
all versions of OpenGL. This is probably the most work to be done.
*Do something useful with the deprecation model*
With 3.0 and higher versions part of the OpenGL API has been deprecated.
Though it's a bad to drop all support for the deprecated stuff, it's also
not a signal to ignore. We should probably be using this information in some
way to improve the package. I think it's probably a good idea to make an
export with and one without deprecated functionality. Maybe even make a
compilation possibility for compiling without deprecated stuff.
*Rework/implement support for matrices*
Some basic support for the use of matrices is missing from the package and
it's needed for some new functions. Some discussion is needed on how we
should add them (only a typeclass vs. datatype).
*Add per OpenGL version export*
It would be nice to have an export/import module for each version so that
you could do "import .....OpenGL.Core31" to import only the functions of
OpenGL 3.1 (and of course similar for the other versions).
*Restructure the internals
**
Rework marshalling*
As stated in a previous mail to this list (see [1]), I want to improve some
of the marshalling, that would in quite a lot of places improve the
readability of the code and the efficiency of coding (at least that is my
theory).
*Restructuring to get it more type-safe*
There are some places where the code could be improved to make it safer (in
the sense that more wrong code it ill typed). For example, GetPName could be
broken up into several separate datatypes for different result datatypes and
sizes.
*Restructure the module hierarchy*
The current structure is that almost all modules(about 55 for me) are in
Graphics.Rendering.GL. Furthermore some of the most important modules are
1000+ lines, this makes it sometimes quite hard to have overview over the
code. This coud probably be fixed quite a bit by moving all deprecated
functionality to it's own modules (I estimate it's about 50% of the code). A
side from that, some modules could be split up in directory form (as with
Texturing and PixelRectangles) to make the code more readable.
A further change could be to export some extra functionality from 'Internal'
modules for people how find that they need that in order to make a function
that isn't in the package.
*Policies*
*Policy on extensions*
Extensions are a major part of OpenGL usability and there for we should
think about what to do with them in the package.
*Policy on testing*
Testing all the workings of the package would be nice, but building a test
suite is quite a lot of work. And thus we should decide how much we should
test or otherwise make sure that the written code is compatible with the
OpenGL specification before including it in an release.
*Policy on documentation*
The current package is mostly undocumented. Most of the functions are the
same in name and working as those described in the OpenGL specification, but
the specification is not something most people want to read. On the other
hand, in my opinion writing documentation is one of the least favourite
tasks of programming. So how much and what should be documented.
Greetings,
Lars Corbijn
[1] http://www.haskell.org/pipermail/hopengl/2011-June/001038.html
