> This is what osgIntrospection and genwrapper does. It doesn't need > any interface files.
Sure, but someone has to maintain the osgIntrospection classes in addition to maintaining OSG. Perhaps that is still less time consuming than adapting the interfaces to some wrapper generator. > My suggestion is to push to get osgPython up to speed on the dynamic > binding side. Once these work well enough you could either use them > as is, or use it as spring board to building static Python bindings. Yes, it makes sense. The entire OSG API could be accesses dynamically and on occation static binds can be created as needed. However, my fear that Python will have to adhere to "lesser" languages ;) and lose it's dynamic and highly object oriented nature. If osgIntrospection is somehow adjusted to languages like C# and Java there will be little to offer a Python programmer. Using languages like Python and Ruby simply as scripting-glue is a great way to waste good language design. I guess I'll just have to sit tight and wait for osgPython to work with OSG 1.2 or latest devel version. Is it even concievable that OSG 1.3 would have Python support via osgIntrospection? /Peter _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
