Hi Marcus,
Marcus Lindblom wrote:
>> 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?
>
Those are not fully decided yet. I would want them, though. ;)
> 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.)
>
The problem I have with reflecting functions in a compiled language like
C++ is the signature. You can;t dynamically construct fundtion calls, so
you can't reall ymake it work generically. Not to talk about all the
additional work to do that. ;)
> 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.)
>
begin/end edit is going away so we don't have to worry about that one.
> 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. :)
>
;)
> 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).
>
Yup. gccxml is really helpful in that respect.
> 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).
>
Sounds good.
> 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.)
>
You're preaching to the choir, here. ;)
Dirk
-------------------------------------------------------------------------
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
