Marcus Lindblom wrote: >Allen Bierbaum wrote: > > >>Marcus Lindblom wrote: >> >> >> >> >>>Nice writeup. >>> >>>The whole FieldContainers framework >>>(factory/serialization/aspect/reflection/plugins) seems to be worthy to >>>mention. (I'm almost thinking of switching to that for our entire app, >>>esp physics thread aspect handling.) Pluggable Image/Scene loaders might >>>be nice to mention, although it's pretty standard for any scene graph >>>system. >>> >>>This has me thinking that it should be possible to adapt fcdProcess to >>>emit boost::python bindings for Fields, so that we get something really >>>spiffy that handles a lot of stuff for free (with this framework not >>>having to belong to a graphics system). >>> >>> >>> >>> >>> >>I hadn't really thought about using fcdProcess to do this. It may work, >>but what I was really hoping was that with OpenSG2 we could put a >>framework in place with the fc's (once they stabalize) to just use the >>reflective interface to automatically discover and create the python >>class definitions at run-time. >> >> >> >That would be nice, yes. But this 'reflective interface' (of which I >have little knowledge at the moment) is it the fields or a >member-function binding, similarish to boost::python? > > The type and field information from OpenSG. I think we could expand it a little bit and make it possible to have pyOpenSG discover the fc-based class types at run-time and dynamically create interfaces for them. Before delving into this though I would like to see the fc code stabilize and hopefully merge ref_ptr and fc_ptr in some way (this would make the binding *much* easier).
>>Right now what I am doing is much more brute-force and uses py++ to >>generate bindings for everything using the "user API". (see: >>https://realityforge.vrsource.org/view/PyOpenSG/WebHome) >> >>In other words I don't interface to the fields at all. I think it would >>be possible but it doesn't seem to be the "real" interface for OpenSG >>and after talking with Dirk I realized that there are places in the code >>where using only the field container interface will not work because the >>code needs the side-effects that happen as a result of calling the >>user-api interface instead. >> >> >> >Indeed. I was thinking that you'd have this tool (fcdProcess or >something else) that produced the boost::python code for all functions >in the XXXBase-class. > > That may be possible, I really never looked into it because the boost::python code to be generated it pretty complex and... well... I am a little scared of the code in fcdProcess. :) But if you have time and want to look into it or just what I have now, I would love to have help with pyOpenSG. :) >That way, you only would have to worry about binding stuff you add >yourself. Which would be kind-of neat. > >Anyway, I'd love to try throwing SWIG at OpenSG and see what happens as >well. .. Later.. after.. :) > > Is there something specific you think SWIG could add that boost.python can't? I am not a SWIG expert, but that last time I looked at all the bindings tools there seemed to be a consensus that for C++ boost.python was the way to go unless you needed some of a custom capabilities of sip. -Allen >Cheers, >/Marcus > >------------------------------------------------------------------------- >Take Surveys. Earn Cash. Influence the Future of IT >Join SourceForge.net's Techsay panel and you'll get the chance to share your >opinions on IT & business topics through brief surveys -- and earn cash >http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >_______________________________________________ >Opensg-users mailing list >[email protected] >https://lists.sourceforge.net/lists/listinfo/opensg-users > > > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
