[realXtend] Re: LudoCraft's Tundra 2.0-preview installer and code is out!

[ilikia]

Hi again Ali, hope you had a nice festival weekend a week ago. Sielun
Veljet... would have been nice to see them again after all these
years.

OK, I managed to make CAVE functionality work in Tundra 2.0, thanks a
lot for the instructions. I've fiddled with the remake of the
PythonScriptModule now and then, but I am just not up to it. It is
just too full of references to the old modules and to the old way to
define scenes and math. Errors after error... And I don't know how to
to rewrite the code, even if I commented out all the compiler errors.

Adding PythonQt to the deps seemed to work, though, by copying the
PythonQt directory from NaaliDeps to Tundra2deps, and by adding the
line 'configure_python_qt()' to the upper level CMakeLists.txt. At
least vs2008 does not complain about '#include PythonQt.h'.

Does anybody else need PythonScriptModule in Tundra2? I have to have
it to make my own code work. I'd really appreciate it if any of you
gurus would have the time to give me advice on how to port the
PythonScriptModule to Tundra2.

-- 
http://groups.google.com/group/realxtend
http://www.realxtend.org

Re: [realXtend] Re: LudoCraft's Tundra 2.0-preview installer and code is out!

[Jonne Nauha]

Hi Ilikia,

Sorry that I havent been more vocal here on the mailing list since getting
back to work on monday. I have done some big efforts for the Tundra2
codebase since then. We are now working in the realXtend naali repo under
tundra2 branch. I have made things build again like cave module. Python is
still not done but I will get to it at some point. I would not use too much
time for that yourself.

I have enhanced our cmake system and how windows finds dependencies. I
automated fetching deps so you dont have to do a manual svn checkout
anymore, and no manual copying of files into /bin. Last night I made a "make
install" step for Tundra2 that you can (later at least) pass a prefix and
you can install your build there with /lib /bin /include stuff like normal.
erno aka e` is working on the linux build for tundra2.

Quick steps to get going

   1. Clone Branch located at
   https://github.com/realXtend/naali/tree/tundra2
   2. Have git.exe in your path and run
win_update_deps_vs2008.bat
   3. Then run 
win_cmake_vs2008.bat
as
   usual

You don't anymore need to have TUNDRA_DEP_PATH or similar in your system env
variables. The scripst will take care you have the latest deps, copy them to
bin for you and when you run cmake the deps path is cached so you never have
to pass it again (unless you really want to change it). If you want to
forget the dep path + all the found deps ofc you can delete CMakeCache.txt.
win_update_deps_*.bat does this for you so you wont get strange results
after updating deps.

Source code has been moved under /src and there is some subdir separations
SDK vs application level. This structure is not final but prepares us for
the future and makes us look like a proper project with an actual src dir ;)
I made static libs build under /lib. I modified the cmake system quite much
to make it nicer and adding cmake/TundraInstall.cmake for "make install"
macros (for all platform, on visual studio right click "INSTALL" project and
select Build!).

I'll keep you posted on python (at least i promise to try and remember :).
The situation there is that we need to remove a lot of dead code. How SDK
gets exposed to .py code and so forth probably stays as is and is not really
hard to make build.

Best regards,
Jonne Nauha
Adminotech developer


On Fri, Jul 22, 2011 at 3:24 PM, ilikia  wrote:

> Hi again Ali, hope you had a nice festival weekend a week ago. Sielun
> Veljet... would have been nice to see them again after all these
> years.
>
> OK, I managed to make CAVE functionality work in Tundra 2.0, thanks a
> lot for the instructions. I've fiddled with the remake of the
> PythonScriptModule now and then, but I am just not up to it. It is
> just too full of references to the old modules and to the old way to
> define scenes and math. Errors after error... And I don't know how to
> to rewrite the code, even if I commented out all the compiler errors.
>
> Adding PythonQt to the deps seemed to work, though, by copying the
> PythonQt directory from NaaliDeps to Tundra2deps, and by adding the
> line 'configure_python_qt()' to the upper level CMakeLists.txt. At
> least vs2008 does not complain about '#include PythonQt.h'.
>
> Does anybody else need PythonScriptModule in Tundra2? I have to have
> it to make my own code work. I'd really appreciate it if any of you
> gurus would have the time to give me advice on how to port the
> PythonScriptModule to Tundra2.
>
> --
> http://groups.google.com/group/realxtend
> http://www.realxtend.org
>

-- 
http://groups.google.com/group/realxtend
http://www.realxtend.org

Re: [realXtend] Re: LudoCraft's Tundra 2.0-preview installer and code is out!

[Ali Kämäräinen]

ilikia,

Festivals - a great opportunity to miss bands...

But to the business: you can delete Vector3dfDecorator.h&cpp,
QuaternionDecorator.h&cpp and TransformDecorator.h&cpp + all references to
those files. That should help a bit at least.

Grey skies,
Ali Kämäräinen

-- 
http://groups.google.com/group/realxtend
http://www.realxtend.org

Re: [realXtend] Re: LudoCraft's Tundra 2.0-preview installer and code is out!

[Jonne Nauha]

How are the new math lib classes exposed to py? I did see that there were
generated converter functions spesificly for the QScriptEngine. Are they
QObjects? I mean if not we still need to make Qt based Decorators like that
to feed them into PythonQt. At least i think so. I am under the impression
that you need to feed qobject classes to the PythonQt. But I might actually
be wrong, will have to ask toni next week when I see him.

Either way, yah I'm cleaning out the module quite a bit. File and source
wise, its in quite bad shape. The maintainers have been just commenting
completely dead code for a long time so its a freaking mess :I I'll try to
get it closer to our standards but not into fulling state today. Need to
expose the math lib somehow at some point. At least things that get exposed
over from EC_Placeable so its usable from py.

Ali any comments on moving stuff under /src? I'd like to hear your ideas
about how to structure the sources to get this SDK vs. application layers
going. I think its already quite nice. My next big move would be to remove
/bin from the repo all together and make it generate itself during the
build. Moving all the data that is there currently will be quite easy to
move under /src/ where the corresponding project is. As I did with my cmake
install support thingie with the macros:
https://github.com/realXtend/naali/commit/b528d36d13a61d39ecb6eb14c27e93f6319a81f8

Best regards,
Jonne Nauha
Adminotech developer


On Fri, Jul 22, 2011 at 5:43 PM, Ali Kämäräinen wrote:

> ilikia,
>
> Festivals - a great opportunity to miss bands...
>
> But to the business: you can delete Vector3dfDecorator.h&cpp,
> QuaternionDecorator.h&cpp and TransformDecorator.h&cpp + all references to
> those files. That should help a bit at least.
>
> 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

Re: [realXtend] Re: LudoCraft's Tundra 2.0-preview installer and code is out!

[Ali Kämäräinen]

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

Re: [realXtend] Re: LudoCraft's Tundra 2.0-preview installer and code is out!

[Jonne Nauha]

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 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

Re: [realXtend] Re: LudoCraft's Tundra 2.0-preview installer and code is out!

[Jonne Nauha]

Alright Ilikia I committed my stuff
https://github.com/realXtend/naali/commit/f2bd3a2ade72223a4262c80af7e04f2c8db13348

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  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 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

[realXtend] Re: LudoCraft's Tundra 2.0-preview installer and code is out!

[ilikia]

Wow guys, you really had a brainstorm this afternoon. Probably
interesting things to come.

Ali: I had already commented out all the code in the files you
mentioned, they did not cause errors. The big problems occurred with
PythonScriptModule and PythonScriptInstance, because they refer a lot
to stuff like Scene::Entity etc., and Scene is defined very
differently now.

Is 1.* going to be terminated completely now? Or developed in
parallel? Of course I can use the versions I've compiled so far as a
backup, but I think that there are others who have built a lot on 1.*,
like people at  the CIE that  I visited a couple of months ago.

Anyway, I'll wait for the official release then. Maybe someone else
will need PythonScriptModule, too, and  the project will advance.

Have a nice holiday guys.

On Jul 22, 8:08 pm, Jonne Nauha  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 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

[realXtend] Re: LudoCraft's Tundra 2.0-preview installer and code is out!

[ilikia]

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  wrote:
> Alright Ilikia I committed my 
> stuffhttps://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  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 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

Re: [realXtend] Re: LudoCraft's Tundra 2.0-preview installer and code is out!

[Jonne Nauha]

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  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  wrote:
> > Alright Ilikia I committed my stuffhttps://
> 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 
> 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  >wrote:
> >
> > >> The new math classes are not currently exposed to Python. The math
> classes
> > >> are not QObjects, nor will be afaik. The QScript

Re: [realXtend] Re: LudoCraft's Tundra 2.0-preview installer and code is out!

[Jonne Nauha]

I did some more work for python
https://github.com/realXtend/naali/commit/b2a25515c384e53bd5c6382bec541711edd2948c

New tundra.py that you import and use the core APIs:
https://github.com/realXtend/naali/blob/tundra2/bin/pyplugins/tundra.py
New apitests.py that you can run using Tundra.exe --pythonapitests to verify
everything works:
https://github.com/realXtend/naali/blob/tundra2/bin/pyplugins/lib/apitests.py

I'm quite pleased how clean I got the main PythonScriptModule.cpp
https://github.com/realXtend/naali/blob/tundra2/src/Application/PythonScriptModule/PythonScriptModule.cpp
Gutted
it from  almost 3000 lines into 600.
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 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.

Todo for PythonScriptModule:

   - .py plugin load system on startup
   - 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.

Best regards,
Jonne Nauha
Adminotech developer


On Sat, Jul 23, 2011 at 12:00 AM, Jonne Nauha  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