Message from discussion
TexturePointer in Python-Ogre
Received: by 10.36.23.10 with SMTP id 10mr1574625nzw.1171896127003;
Mon, 19 Feb 2007 06:42:07 -0800 (PST)
Return-Path: <nzmill...@gmail.com>
Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.238])
by mx.google.com with ESMTP id x35si1192455nzg.2007.02.19.06.42.06;
Mon, 19 Feb 2007 06:42:07 -0800 (PST)
Received-SPF: pass (google.com: domain of nzmill...@gmail.com designates 66.249.82.238 as permitted sender)
DomainKey-Status: good (test mode)
Received: by wx-out-0506.google.com with SMTP id i31so1768663wxd
for <python-ogre-developers@googlegroups.com>; Mon, 19 Feb 2007 06:42:06 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws;
d=gmail.com; s=beta;
h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
b=ZNzO9SNYUsgZqVv57R+/PKHIGnCIFbTdvNIjwz5umcbZFkUbzjZwOkWF24RRHhwSN9nUdQ7dJL4MAvoR0iBhGulxSZbvPGUAAtY81YN+YucrkKfG9yVhLJDKw0dwHSjyGiK/YzuXp2ZxVV4HPtrngQhIIiHmTq/+QLEzbRXX6eU=
Received: by 10.90.98.10 with SMTP id v10mr7084280agb.1171896125560;
Mon, 19 Feb 2007 06:42:05 -0800 (PST)
Received: by 10.90.31.17 with HTTP; Mon, 19 Feb 2007 06:42:05 -0800 (PST)
Message-ID: <3ec55cef0702190642w6182fbe6p4485e70bf18a7dc6@mail.gmail.com>
Date: Mon, 19 Feb 2007 22:42:05 +0800
From: "Andy Miller" <nzmill...@gmail.com>
To: python-ogre-developers@googlegroups.com
Subject: Re: TexturePointer in Python-Ogre
In-Reply-To: <1171895762.462374.174820@s48g2000cws.googlegroups.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_Part_23638_13019457.1171896125517"
References: <1171842483.821215.242510@k78g2000cwa.googlegroups.com>
<3ec55cef0702181716u7fba00f3v2e76e62c52eae25d@mail.gmail.com>
<7465b6170702182151w78e2de8bkec19310fa2564e3@mail.gmail.com>
<3ec55cef0702190116v62a5525bo3a7b76ea60cf75bb@mail.gmail.com>
<7465b6170702190210q42b0f5bfpabaedc4c9da75a1a@mail.gmail.com>
<7465b6170702190210s19b8a1a2u5005aec3f6435226@mail.gmail.com>
<1171895762.462374.174820@s48g2000cws.googlegroups.com>
------=_Part_23638_13019457.1171896125517
Content-Type: text/plain; charset=ISO-8859-1
I won't get the texture pointer stuff done until tomorrow - a full compile
is underway with a lot of other fixes etc..
I'll update the SVN now with what I have, but if you have any issues just go
back a version :)
Cheers
Andy
On 19/02/07, Mike Handverger <mike.handver...@gmail.com> wrote:
>
>
> That sounds good. If you want to check in the manual fix, I can give
> it a try on Linux. I've been meaning to test the new stuff on Linux as
> Andy asked and should probably have the time in the next day or so. In
> any case, this would be a great way of handling this issue.
>
> Thanks,
>
> Mike
>
> On Feb 19, 5:10 am, "Roman Yakovenko" <roman.yakove...@gmail.com>
> wrote:
> > On 2/19/07, Roman Yakovenko <roman.yakove...@gmail.com> wrote:
> >
> >
> >
> >
> >
> > > Okey, here is my solution, after some thought. PyOgre provided "less
> than
> > > optimal" interface for factory classes. Casting it is not something
> that
> > > could be
> > > easily explained to a Python user. The better interface is to return
> the
> > > right class.
> >
> > > Solution. We need to wrap every factory and every create method within
> it.
> >
> > > boost::python::object TextureManager_getByName(const std::string&
> name){
> > > ResourcePtr r = TextureManager.getSingleton().getByName( name );
> > > if( dynamic_cast< Texture* >( r.get() ) ){
> > > return boost::python::object( TexturePtr( r ) );
> > > }
> > > if( dynamic_cast< Material* >( r.get() ) ){
> > > return boost::python::object( MaterialPtr( r ) );
> > > }
> > > ....
> > > return boost::python::object( r ); //unknown type
> > > }
> >
> > > Than we should expose this function, instead of the original one. This
> > > will give
> > > our users intuitive behavior.
> >
> > > Of course, this task could be automated. I mean we can create a class,
> > > which will
> > > generate a code like this for every factory. But I suggest we will try
> it
> > > first on
> > > Resource derived classes and factory manually.
> >
> > > What do you think?
> >
> > > --
> > > Roman Yakovenko
> > > C++ Python language binding
> > >http://www.language-binding.net/
> >
> > --
> > Roman Yakovenko
> > C++ Python language bindinghttp://www.language-binding.net/
>
>
> >
>
------=_Part_23638_13019457.1171896125517
Content-Type: text/html; charset=ISO-8859-1
<div>I won't get the texture pointer stuff done until tomorrow - a full compile is underway with a lot of other fixes etc..</div>
<div> </div>
<div>I'll update the SVN now with what I have, but if you have any issues just go back a version :)</div>
<div> </div>
<div>Cheers</div>
<div> </div>
<div>Andy<br><br> </div>
<div><span class="gmail_quote">On 19/02/07, <b class="gmail_sendername">Mike Handverger</b> <<a href="mailto:mike.handver...@gmail.com">mike.handver...@gmail.com</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><br>That sounds good. If you want to check in the manual fix, I can give<br>it a try on Linux. I've been meaning to test the new stuff on Linux as
<br>Andy asked and should probably have the time in the next day or so. In<br>any case, this would be a great way of handling this issue.<br><br>Thanks,<br><br>Mike<br><br>On Feb 19, 5:10 am, "Roman Yakovenko" <
<a href="mailto:roman.yakove...@gmail.com">roman.yakove...@gmail.com</a>><br>wrote:<br>> On 2/19/07, Roman Yakovenko <<a href="mailto:roman.yakove...@gmail.com">roman.yakove...@gmail.com</a>> wrote:<br>><br>
><br>><br>><br>><br>> > Okey, here is my solution, after some thought. PyOgre provided "less than<br>> > optimal" interface for factory classes. Casting it is not something that<br>> > could be
<br>> > easily explained to a Python user. The better interface is to return the<br>> > right class.<br>><br>> > Solution. We need to wrap every factory and every create method within it.<br>><br>> > boost::python::object TextureManager_getByName(const std::string& name){
<br>> > ResourcePtr r = TextureManager.getSingleton().getByName( name );<br>> > if( dynamic_cast< Texture* >( r.get() ) ){<br>> > return boost::python::object( TexturePtr( r ) );<br>
> > }<br>> > if( dynamic_cast< Material* >( r.get() ) ){<br>> > return boost::python::object( MaterialPtr( r ) );<br>> > }<br>> > ....<br>> > return boost::python::object( r ); //unknown type
<br>> > }<br>><br>> > Than we should expose this function, instead of the original one. This<br>> > will give<br>> > our users intuitive behavior.<br>><br>> > Of course, this task could be automated. I mean we can create a class,
<br>> > which will<br>> > generate a code like this for every factory. But I suggest we will try it<br>> > first on<br>> > Resource derived classes and factory manually.<br>><br>> > What do you think?
<br>><br>> > --<br>> > Roman Yakovenko<br>> > C++ Python language binding<br>> ><a href="http://www.language-binding.net/">http://www.language-binding.net/</a><br>><br>> --<br>> Roman Yakovenko
<br>> C++ Python language bindinghttp://www.language-<a href="http://binding.net/">binding.net/</a><br><br><br>
------=_Part_23638_13019457.1171896125517--