On to, 2011-02-03 at 01:46 -0800, HartsAntler wrote: > Hi All RexDevs, There is also the realxtend-dev list btw -- this is supposedly the users list. I suggest we continue there not scare people with code :) .. I reply here now anyway so people know a reply did come, but let's take continuation there.
Probably good actually you posted the first post here though, 'cause the add-on system is of course an end user feature targeting easy use. > be adapted for addons. Whatever interface we have for enabling/ > disabling addons, it can simply comment or uncomment all entries in > the addon .ini file. Yes. > I see that autoload.py:48 inits the class as modinst and appends it to > circuitsmanager. I assume then the class must be a subclass of > circuits.Component. This is not something that should not always be > imposed, some addons may not use circuits and may run via a subprocess > or some other method. Short answer: yes. Long answer, that tells why it didn't make sense untill recently, below. People not interested in this history & details, please skip the rest of this post :) This is a bit of a historical artefact. Amazing how much history and changes there is in a project where the first lines of code were written only 2 years ago! A brief (I hope!) explanation .. also 'cause you are an expert in c-py interfacing techs by now (Brett has even made Blender a Python module :) Initially Naali was built around an own custom event system, Naali events. I wasn't that much involved then, but on father's leave, and also our company wasn't working directly on reX then yet. Did participate in some of the planning talks, and was hoping that we could use some existing event system -- didn't know any suitable c/c++ one offhand though, dunno if anyone looked at things like gevent or mbus. Then I joined in to add py support (which ppl wanted I guess 'cause the server side scripting in modrex is py too), and we saw that it would work by making those Naali events work for py too. Looked into boost::python and pybindgen and swig and such for wrapping Naali internals, but then decided to make first tests with just hand written py c api code to see how things work. It wasn't trivial to use the usual tools work for embedded contexts and especially to get them working at all within the Naali Framework. Added some manual code to forward Naali events to the py side, and didn't wanna reinvent an own event system there so tested Pyglet and Circuits and looked at a few others, and decided on Circuits. I also unified the module system so that also the module update function, which is function called Update in c++ modules, is implemented via and update Circuits event for py modules. Then later we decided to start Qt for UI, instead of the initial GTK .. just to have something that gives nice enough GUI widgets. I didn't know qt from before, but we quickly learned that the signal system there could work for what we used the own events earlier. Ryan wrote these studies http://wiki.realxtend.org/index.php/Qt_Event_or_Signal_as_a_replacement_for_Naali_Event_system http://wiki.realxtend.org/index.php/Qt_Script_as_a_means_of_extending_and_overriding_internal_Naali_behavior and I tested making custom camera code overrides with qt signals as well. I was then really lucky that hadn't jumped into boost::py and such business, 'cause also Qt has a mechanism for exposing c++ things to scripting .. which doesn't require static language specific bindings and works for multiple languages (PythonQt for py, QtScript for js and there's also QtLua). JS was in my plans already from before, 'cause figured it would be good for the secure sandbox. So we've transformed Naali to be a qt app with all modules etc. as QObjects for scripting support. Regarding events, the current situation is a bit of a hybrid of the old pre-qt and new with-qt things. Some things are still purely Naali events, like when new network traffic comes with LLUDP. But everything new, like Entity-Actions, is implemented with qt signals. Now to your point: making a py thing that uses e.g. subprocess to execute. If you just did that, launched a subprocess when Naali starts, how would that be useful if you would not be able to communicate with it? If your code in the other process had no way to get info from/to Naali and vice versa. That's why I think you always need something that makes Naali call your code. Either periodically or based on user input or something happening in the scene etc. Until recently the way to get periodical calls was the module Update function, propagated as a circuits event for py modules by default. However now there is a Qt signal for that, Frame.Updated -- was added for JS where we haven't been exposing any Naali events. Same goes for keyboard input and mouse clicks and such -- they were previously Naali events only, and those work for py too, but nowadays there are also Qt signals for them. So now circuits isn't required for py code to be useful either, and we should get rid of the restriction. However, there still are many things that are only Naali events -- like the logout event when leaving a LLUDP server, so most (if not all) modules currently in use by default require it anyway. On the JS side, there's now a nice simple mechanism for automatic loading: anything in jsmodules/startup/ is loaded .. at startup. That's how Tundra has the menubar and free camera. One option is to adopt that startup/ dir to the py side too for things that don't need circuits (e.g. for the f11 live reloading support which is nice for developing, but typically requires co-operation 'cause the code has to remove GUI widgets and menu entries and such to not get multiple when it is reloaded). Other would be to extend the autoload.py / *.ini system so that you can put refs to plain py files that are just executed, but keep the easy way to have the circuits modules too. Let's think about this a bit, any comments are welcome. BTW the circuits usage is on the py side only and interchangeable (also circuits itself is pure py) -- if someone wants to write a similar module manager in e.g. Twisted, that doesn't require any c++ side changes .. just making pymodules/core/modulemanager.py use that instead of the circuits one. ~Toni -- http://groups.google.com/group/realxtend http://www.realxtend.org
