Hi! Thanks for the swift response, much appreciated. It's actualy one of the things that makes OSG such a gem!
> Please re-read my previous email - I offer three options, you seem to It seems I didn't fully comprehend point 2. It does sound interresting. > I also have to point out that most OSG users don't continuously go > subclassing from OSG classes - they just create a scene, modify small > elements of that scene, they don't need to subclass everything. The > places that you will subclass is things like event handlers and node > callbacks, one needs to make sure that these are easy to create. This > will scoop up 95% of end users. What you describe sounds like the procedural way to do things, not the object oriented way. As an example, everything that goes into a scene graph (including the scene graph itself) should be part of the usable object orientation of the API. It is the Python way of doing things. Perhaps the best way is to start from the top rather than from the bottom. That is, start with converting the simple examples and add bindings as you need them to run the example instead of trying to 1:1 map the entire API and then figure out what is needed. I have to admit that I am somewhat confused and intimidated by the size of such an undertaking, regardless of tactic. > So rather than take the line of can't do that, must do that, please > soften a little, you can do a lot without needing to be 100% of > everything that you could ever think of. For those cases that you > slip off the well beaten track that are still options like dropping > down into C++. OK, perhaps you are right. I simply want to avoid the akwardness of using Python as "glue" rather than a full programming language. I would even consider taking the API one step further than just simple bindings, perhaps certain parts of OSG will work very well with Python fundamentals, like generators, context managers, metaclassing, duck-typing and mix-in's, so they should be part of the Python OSG API where applicable. My plan was simply to make a 1:1 binding that I could use to design the final Python API with, in the end I am sure that I could safely discard large portions of it, just as you said. > I would very much like to get an easy and maintainable solution for > 95% of normal users, and for power users it'd be great to easily cater > for them as well, but given they are power users then going a bit off > road occassionally needn't be a show stopper. The problem now seems to be that a lot of people are inventing this solution over and over because none of the previous ones caters to their needs. Perhaps adding a generic binding wrapper to the OSG project that can provide any language (well, supported languages) with the low level bindings they need to build fully compliant API's on? Users could simply extend that generic wrapper to include other portions of the API on need-to-use basis. Meanwhile, that number two option sounds a lot more sane than trying to run through all interfaces for the entire OSG API and SWIG-generate the code like I have been trying to. Could you get into details on your plan/thoughts regarding what solution you think would be best (1-3) and how you would proceed? /Peter _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
