Allen Bierbaum wrote:
> Marcus Lindblom wrote:
>
>> Allen Bierbaum wrote:
>>  
>>
>> [snip on binding dynamically to OpenSGs reflective interface]
>> 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).
Couldn't you just use ref_ptr everywhere in ? :) .. or the 2.0 c-ptr's 
might ease the pain?

Hmm, I'm not sure it would work to create interface dynamically. It 
would make more sense to bind to user-functions rather than fields. 
Also, you need to call functions sometimes (window->render()) so there's 
no way around that (unless, as I said, those functions also were 
available reflectively.)

When binding to fields, you need some way to do begin/endedit though 
(this is what I do in my OpenSG<->xml-bindings). This will, IIRC, be 
baked into functions for 2.0, so then we need to bind to functions 
anway. So what you are doing with py++ is the right way anyway. (What I 
have been thinking of, time to time, is that there should be a generic 
script binding system, but maybe that will come out of the langbinding 
site in time.)
>> 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. :)
I haven't looked. Maybe I shouldn't. (losing sanity points by gaining 
knowledge :)  .. My thesis work was a code-generator in Haskell 
(http://www.yar.nu/macke/hspark/) which produced C++ (and planned to do 
GLSL). And Haskell is pretty nice for those things, so I have some 
familiarity with such contraptions.

But fcdProcess seems to be just a xml->cpp generator, right, so you 
could probably roll your own there, if you wanted. But given that py++ 
does the job pretty good from the generated sources, there's no need in 
doing something like that. I withdraw my suggestion. :)
> 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. :)
Well, it certainly looks like it's generating useful stuff!  (But whadda 
ya mean haven't attempted on windows??!?! ;-) I have to dig a bit in 
py++, pyste and python before I can even beginning to sound to know 
something about this, but think I can see this going places. :)

I didn't know py++ was this good. It certainly seems to be at least as 
capable as swig (which I have been messing with), if not better. (since 
it uses gcc, which makes perfect sense. That is my main grip against 
swig, and a quite serious one at that).

All I can say that I won't have time to do anything pythonish until 
after christmas (i.e. the next project) and I have to be quite 
persuasive about it to my bosses, but it might happen. If we go python 
here (and pigs start to fly), I will use some wrapper. Using the same 
wrapper as OpenSG makes sense, because I need interop between my python 
bindings and OpenSG. Otherwise, I'll might have to wrap OpenSG by myself 
(I don't know how compatible different bindings are). So in that case I 
should be able to help you out getting things going (and since we use 
windows, I would probably tackle that part of it).

Sorry for being vague on promises though, but I'm getting paid to code, 
so I therefore must code stuff which someone will pay for. (Fancy 
frameworks seldom sells, working applications does .. getting enough 
time & money to be able to work long-term is hard.)

Anywya, I tried looking around to get some grips on the status of 
pyOpenSG, i.e. current issues and todo-list. But there seems to be 
little of that. What are the current issues & progress?

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

Reply via email to