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. > 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. > 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. 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 :) 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. > Jonne Nauha ~Toni > On Sat, Jul 23, 2011 at 12:00 AM, Jonne Nauha <[email protected]> wrote: > That would be helpful if you can give concrete use cases. But I recon youll > do mighty well if we just expose all the SDK APIs and the full chain of scene > -> entity -> component -> attribute. The problem with the old python module > is that there are all kinds of special getters and setter and own magic how > to access things. We must fix this and make it similar to C++ and JavaScript, > all languages should access things in Tundra with same calls to framework > objects/APIs. > > Tundra 2.0 is just a name/version, it could be as well Tundra 1.1 or 1.5. It > just means "we are making big changes, just look at the version number". > Meaning that when you start working with the 2.0 SDK you should already know > that you might need to port some code lines to newer calls etc. :) I can't > say for everyone but we at Adminotech want to move to 2.0 full time, we think > its a step in the right direction. So far what I have seen, 2.0 brings alot > of nice new features, polishes the code that was already there, removes years > of "legacy" code and cruft that we really don't need. I am confident once > people get to see the new stuff they will be happy to move along. The > advantages for developers are huge, easier code base to work all around. So > when Qt releases 4.8 I don't think anyone there still works on 4.7 or 4.6 > versions of the code base, so I dont see a reason for us to do so either :) > > CIE has their own c++ code and scripts, and I actually visited there > yesterday. But with the talks I have had with them they want to move to the > new stuff when their timetables allows it. I/we need to properly first port > existing code into 2.0 and have a solid working build on linux before they > can jump along. But knowing the guys there and the code they are working > with, this will be a trivial max day per module port. It took me 10 minutes > on some modules to have a working 2.0 plugin from old module code :P > > I can tell everyone aswell that the dreaded code port from tundra to tundra > 2.0 is very very simple and minimal work for the benefits you will actually > enjoy once its done. I haven't ported JavaScript or python yet, but I cannot > see more than search and replace stuff and some minor things with the new > math lib that you will need to "learn". So I encourage people not to fear > this jump too much even if the talks were controversial here at some point. I > might have been the most afraid how much our company code will have to be > changed, but now I see no problems :) If you have probs please use the > mailing lists, we are here to help. > > Long live 2.0! > > P.S. But as you said propably good to wait for our first rex release, we will > do that once we get things sorted out. That might take some weeks though as > everyone is on holiday and I cant make decisions alone even if I am the > windows "release master". > > Best regards, > Jonne Nauha > Adminotech developer > > > On Fri, Jul 22, 2011 at 9:46 PM, ilikia <[email protected]> wrote: > Thanks again, I'll look at it next week. Might even try to think about > what kinds of methods the new tundra.py module would need. > > On Jul 22, 9:25 pm, Jonne Nauha <[email protected]> wrote: > > Alright Ilikia I committed my > > stuffhttps://github.com/realXtend/naali/commit/f2bd3a2ade72223a4262c80af7e... > > > > <https://github.com/realXtend/naali/commit/f2bd3a2ade72223a4262c80af7e...>Please > > do read the commit msg and understand i did not test this yet. You may do > > that if you check out our tundra2 branch like instructed earlier. I don't > > have time to test and finalize it now :) But it builds now. One thing I > > changed is the python '_naali' import to '_tundra'. So we need to make > > tundra.py that does the equivalent things as naali.py before (provides all > > the nice funcs and APIs). > > > > Best regards, > > Jonne Nauha > > Adminotech developer > > > > > > > > > > > > > > > > On Fri, Jul 22, 2011 at 8:08 PM, Jonne Nauha <[email protected]> wrote: > > > Actually we have discussed this with Jukka from Ludo (and with Toni for > > > many years moving sources to /src). What was discussed with Jukka before > > > he > > > left for summer holidays was the SDK vs. app level split being more > > > strict. > > > I have only done initial steps to do this separations. And > > > I acknowledge that after everyone gets back things might still change, so > > > its been on my mind. > > > > > The idea Jukka had was to move the application layer to a different repo, > > > that would then be fetched as a git submodule on top of the SDK, or even > > > just pointing TUNDRA_SDK_ROOT to the app layer build system (this would be > > > optimal imo). And the work I have been doing now supports all those > > > possibilities once we decide something concrete. > > > > > P.S Yeah dont spend too much on code, have a nice holiday ;) > > > > > Best regards, > > > Jonne Nauha > > > Adminotech developer > > > > > On Fri, Jul 22, 2011 at 6:44 PM, Ali Kämäräinen > > > <[email protected]>wrote: > > > > >> The new math classes are not currently exposed to Python. The math > > >> classes > > >> are not QObjects, nor will be afaik. The QScriptBindings bindings > > >> generator > > >> (found in JavascriptModule) can be probably extended to generate Python > > >> bindings too. Whether they will be done using the decorator technique or > > >> not, I don't know atm. The shape of PythonScriptModule and bin/pymodules > > >> is > > >> horrible indeed, hear hear, and some major cleanup is needed. > > > > >> I haven't paid much attention to the stuff that you have been working on > > >> the tundra2-wip branch as I'm currently on my summer vacation, but what > > >> I've > > >> glanced, there seems to be some good stuff happening there. But if I were > > >> you, I wouldn't spend too much of a time yet fully restructuring the > > >> whole > > >> project on my own as no other Tundra developer party have been consulted > > >> in > > >> any way on the matter, nor any meetings (irl or irc) have been held. So > > >> my > > >> advice would to hold your horses a bit, and it to start working on this > > >> matter later in August. > > > > >> Grey skies, > > >> Ali Kämäräinen > > > > >> -- > > >>http://groups.google.com/group/realxtend > > >>http://www.realxtend.org > > -- > http://groups.google.com/group/realxtend > http://www.realxtend.org > > > > -- > http://groups.google.com/group/realxtend > http://www.realxtend.org -- http://groups.google.com/group/realxtend http://www.realxtend.org
