First of all I'm not sure if you peeked at the code (propably not, you are
on holiday after all :) but I have reimplemented PythonScriptModule
<https://github.com/realXtend/naali/blob/tundra2/src/Application/PythonScriptModule/PythonScriptModule.cpp>and
made a new TundraInstanceDecorator
<https://github.com/realXtend/naali/blob/tundra2/src/Application/PythonScriptModule/TundraWrapper.h#L10>and
TundraDecorator<https://github.com/realXtend/naali/blob/tundra2/src/Application/PythonScriptModule/TundraWrapper.h#L30>.
The instance decorator is there for making new functions into any Tundra
QObject, we did not use this before but I think its the way to go. This way
we can remove all *Raw() getters/setters/emitters from eg. Scene.h but still
have them present in python so they are callable. The fact is I dont think
we can live without *Raw() in python as I did not find a way to do a generic
function for boost::shared_ptr, but maybe it is possible. You can do cast
functions for "ComponentPtr" and return back a QObject, that could be one
way, but I could not make the C++ casts work from the void* it provides, but
it might be possible still.
This requires a wrapper factory for PythonQt:
class TundraWrapperFactory : public PythonQtCppWrapperFactory
{
...
QObject* TundraWrapperFactory::create(const QByteArray & name, void
*ptr)
{
if (name == "ComponentPtr")
{
// Cast the void* to boost::shared_ptr<IComponent> and return
the .get() IComponent* (which is QObjcet*)
}
}
};
As said I already tried this but could not get the casts to work. But maybe
someone smarter than me can get it working.
On Mon, Jul 25, 2011 at 2:26 PM, Toni Alatalo <t...@playsign.net> wrote:
> On Jul 23, 2011, at 5:06 AM, Jonne Nauha wrote:
>
> The python side is now missing the modulemanager.py implementation (the
> circuits one), but that seemed to be full of legacy things as well. I think
> we will see how we implement that in the new things. I guess many people
> liked doing those Circuits.Component or did they? I mean now that we have
> the FrameAPI you can get frame updates without the whole
> modulemanager/circuits doing it for us. I think it could be
>
>
> Yep Circuits was put there basically to expose the old event system to py -
> module updates, and then internal events which we used to have for keyboard
> & mouse input, network messages etc. before Qt. Also much of the C++ code in
> the Py support module was to forward those events, and then some utilities
> old rex stuff.
>
> Circuits is a nice system for making even large applications with clean
> components that send events to each other, but not something that is
> required by our default distribution in the future necessarily. Exactly
> because Qt now gives the frame updates, but not only those but also all the
> other things like mouse & kb input, info about incoming network client
> connections .. and of course our internal scene EC attribute changes etc.
> (also for that there used to be Naali events).
>
> If someone, like Ilikia, likes Circuits and wants to keep using it for his
> own UDP server etc, he can easily just either install it to the system or
> put the dir in his Naali/Tundra py lib dir. I can help with that, but it's
> really trivial.
>
Circuits module manager is implemented and tested to work, with
pyplugins.ini saying what things to auto start. But I found it nicer to have
pyplugins in config.xml and have the c++ thing boot them up on startup, I
also implemented this already, the circuits module manager is committed also
but its startup is currently commented out from the C++ with
notes<https://github.com/realXtend/naali/blob/tundra2/src/Application/PythonScriptModule/PythonScriptModule.cpp#L424>
as
I think we dont really need it. But as I made the effort to rewrite is all
from scratch basically I decided to commit it to the repo if we would need
it some day, but when the decision is made we can remove the code.
>
> enough if we just implemented a thing that loads startup .py plugins just
> like the js ones are defined now aswell in the startup config (see here
> https://github.com/realXtend/naali/blob/tundra2/bin/viewer.xml) Imo we
> should just make python script loading with the same system and forget all
> the rest. We will see what toni thinks when he gets back from holiday.
>
>
> Yah the .ini with all the parts seemed nice, no need to differentiate c++ /
> js / py in configs but unified is best. Originally they had to be separate
> as semantics of c++ and py modules were so different, but with the new
> plugin concept unification seems simple indeed.
>
This is now done in
https://github.com/realXtend/naali/blob/tundra2/src/Application/PythonScriptModule/PythonScriptModule.cpp#L243
and
is called as the last thing in PostInitialize() when all things should be
ready for py scripts to run.
>
>
> - Expose new math lib to python (at least what EC_Mesh, EC_Placeable
> etc require for full functionality).
> - Possibly make a system for exposing classes outside PythonModule to
> PythonQt so that it does not have to link to everything. I'm not really
> sure
> how this can be done. Either PythonModule needs to link to everything vital
> or other stuff needs to link to PythonQt or something. I guess the first
> option is much better.
>
>
> I thought I mentioned the math classes in some mail already, but perhaps it
> was only in commit messages. The same technique that we use in 1 for the old
> math classes works -- the PythonQt decorator classes. They are a nice tech
> that PythonQt provides for exposing *non-qobject* c++ classes. I think nicer
> actually than what QtScript provides for Js (Jukka doesn't like QScriptValue
> and considers dropping JS at Ludo, and perhaps using e.g. Py instead, but
> that's another story).
>
> It seemed quite simple to port the old VectorDecorator and
> QuaternionDecorator etc. in PythonScriptModule over to the new math lib.
> Like for JS, the change of Vector3 and such types doesn't need to show to
> the higher level lang - old basics can remain compatible.
>
The old decorator classes have been removed and I made
TundraDecorator<https://github.com/realXtend/naali/blob/tundra2/src/Application/PythonScriptModule/TundraWrapper.h#L30>
in
their place, I left AssetReference there and added type() to it. The new
math lib classes are to be added there. The downside of this is in c++/js
placeable.pos.x is a attribute and you access it without calling a function.
With this decorator stuff there cant be properties so you have to call
placeable.pos.x() to get the value so py will be slightly different than
other languages, but i guess thats ok.
>
> As said in an earlier post, we (at Playsign) need good Python support in
> Tundra for the WebSocket server for WebNaali, so was planning to port it
> over when time is ripe for switching to 2 in that work (not very soon, was
> thinking late August or so .. but possibly sooner now if your porting work
> was helpful already :)
>
You can run the py server already, just remove the circuits.Component stuff
and make things work with the framework/api provided signals, you should be
able to find equivalents there. Then add <pyplugin
path="webserver/webserver.py" /> in the config xml you will be using.
> Am working one day now but then continue holiday for a week, will look
> these commits at some point.
>
> Oh about the script-exposing & linking things -- I looked at bit at one
> point and think that with the old service mechanism it would have been
> possible to put a RegisterScriptClass thing to framework, that would then
> forward it to the available scripting support modules. I think that leaves
> the linking prob though, so the Js and Py and possible Lua etc modules would
> need to link against all the parts they expose. Which is possibly ok? Now
> many places (like the Tundra module) use QtScript directly to have the dep
> vice versa, which is not awful as that Js support lib is in Qt itself .. hm
> I guess simply using IFDEFs could work to keep it optional still, if someone
> wants a build without Js support. Perhaps some registration macro with
> ifdefs inside could work to register things in-place in core & modules for
> the langs that are configged to use.
>
Even if we have things register classes to framework and would get the
QObject ptr I think the registration to PythonQt will only work if we have
the headers for the class to get the Class:staticMetaObject out from it. I
thin qobjPtr->metaObject() wont do the same trick, but we will have to see.
I guess we just have to link python module to use everything essential and
make it load last as it depends on "everything". The problem here is just
that when you make some plugin that introduces a new EC you would always
need to go and modify python module to link agains it and add the thing
there. I have done conditional EC registeration with #ifdefs but I we dont
have a system to do that with full modules/plugins yet. You either depend on
a module to be there or you dont, and if you do it has to be in the build or
you wont build.
> Jonne Nauha
>
>
> ~Toni
>
Best regards,
Jonne Nauha
Adminotech developer
--
http://groups.google.com/group/realxtend
http://www.realxtend.org
