Re: Significant restructuring of the 3.x codebase

Mark Heslep wrote:
> Mike C. Fletcher wrote:
>   
>> I've just checked in a fairly significant restructuring of the 3.x 
>> (OpenGL-ctypes) codebase.  What this does is to use the latest ctypes 
>> auto-generator (actually a fairly heavily refactored version of it) to 
>> produce a separate package hierarchy (OpenGL.raw) which contains the raw 
>> OpenGL C-style API.  This API can be used by ctypes-aware code that uses 
>> C-style interfaces, it also allows for coding around problems where the 
>> PyOpenGL abstraction layer happens to get in the way.
>>
>> One thing to note is that all of the constants and functions are now 
>> produced by the auto-generator, this means that there is sometimes more 
>> machinery in the module than you would expect (e.g. the GLX module now 
>> has large parts of the X API).  At the moment I'm thinking (in the case 
>> of GLX) much of that machinery is actually useful (if somewhat 
>> misplaced).  e.g. the functions for screen saver development are likely 
>> in there now.  Probably filter them out at some point I suppose.
>>   
>>     
> It strikes me that a 'raw' API release like this, followed lease by or 
> released concurrently with a more sophisticated Pythonic API, is the 
> model to follow for most Python ports of mature C/C++ projects. 
I was apparently unclear.  By "separate package hierarchy" I meant a 
sub-package of OpenGL whose structure mirrors that of the main package 
hierarchy.  That is, it will all be distributed together for the OpenGL 
package.  What may happen is either that Pyglet uses the auto-generator 
to create their own copy of the hierarchy (in pyglet.GL).  The other 
option is to make the OpenGL package a setuptools namespace package, 
though I'm not sure that would work particularly well with the modules 
right at the OpenGL.* level.
> It 
> lowers the transition bar for both the existing user base and the Py 
> port developer since a) the C/C++ users don't have to learn a new API on 
> top the required Python newness, b) the documentation is essentially 
> already in place*, c) the autogen nature of the raw port makes it easier 
> to maintain absent the full concentration of the primary Py developer, 
> and finally d) as consequence of a,b,&c the bug reports are likely to be 
> more valid/correct. The Pygame ctypes port, with all its good work, is 
> illustrative of the problems caused by skipping the raw API (e.g. 
> threatened forks etc.)
>   
Hadn't heard anything about that.  I actually see the "raw" API as 
something of a specialist's feature.  It doesn't really make a 
particularly useful API to have to code every little C idiom in Python, 
so you have to have a special reason for doing it, such as needing to 
get around a Python abstraction layer problem.  Anyway, if it makes it 
easier for a C coder or the Pyglet guys, yay :) .  Even if it doesn't, 
it makes for a more consistent layout for the package and gives easy 
access to the raw API for advanced coders, so we'll likely go this way.
> * this BTW makes it straightforward to auto include the documentation as 
> Py doc strings in the raw module.
>   
There's already basic documentation in the raw module.  The thing to 
keep in mind is that PyOpenGL's online documentation is based on the XML 
docbook source for OpenGL, GLUT and GLE, and the resulting generated 
files are *big* (about 8.9MB) and not particularly pydoc-friendly, not 
really something you want to include in the source-code.

Have fun,
Mike

-- 
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
PyOpenGL Homepage
http://pyopengl.sourceforge.net