First of all: Thank you very much for your effort!!
Your changes are looking sweet.
(Especially this: "Prevented occasional crashes related to the native environment trying to dispose an object twice")
I have started to commit various 1.7.4 enhancements to my BitBucket fork
Good idea.
I'm not positive what the best way to do pull requests is since I've got a fairly diverse set of little enhancements.
I'm not shure if it's the best way, but I would say that you do a commit to your fork for each little enhancement. Then it's good for others (and yourself) to understand the purpose of each code modification.
I don't mean each line of code, I mean the changes for one feature / enhancement.
By use of Mercurial and BitBucket it should be easy to push changes from your repository to the main repository. It's also possible to just push a subset of changes.
I believe I have successfully merged all of my 1.7.4 enhancements into my BitBucket fork
Oh, you already did it. Good boy.
I would greatly appreciate if someone could test out the changes
When I find some time, I want to build Mogre by your code and use the binaries in my Mogre project.
It's no complete check, but if there are problems, I can tell you details.
the best way to submit a pull request to the main repository
One easy way would be to change the URL in TortoiseHG form your repository to the main repository.
You wrote, you are not shure about the usage of Mercurial. So I like that you created a fork for learning by doing.
BitBucket offers nice possibilities to push changes to an other repository (e.g. our main), but currently I don't know how to do that. I think there is a description on the website.
When you are shure that you are confirm with Mercurial, I would like to give you write access to the Mogre repository.
Fixed the error in ManualObject that prevented various functions from being wrapped
I used ManualObject much, but I never saw missing functions. Can you tell me an example?
Ported additional functionality in the following classes
In January 2012 I added
important changes to the managed classes Vector3, Matrix3 and Quaternion.
Please check, if these are still inside of your ones.
(The answer should be yes, if you modified the code of the main repository after January 2012.)
I simply wanted to make sure that the new stuff was ending up in the build.
You are still afraid of trying out the MogreBuilder, although the usage is so easy.
Branches in Mogre repository
I checked the commits for the last year and saw an important point:
There were
many many commits, but they were applied
only to the default branch.
The
TerrainAndPaing branch wasn't changed after January 2012.
Mercurial offers an option to merge commits from one branch to an other one. Unfortunately I don't know how.
I think it's important to do this (and before pushing the changes to an internet repository there should be a quick test if the code can be build and the binary files run).
An other option would be to merge the commits of the
TerrainAndPaging branch to the
default branch.
But I can't say if this is good, because the modifications for wrapping the paging/terrain components are incomplete and more like a quick and dirty style (as I read from the previous maintainer mstoyke).
Maybe this could make Mogre instable? Maybe it doesn't care as long as some body doesn't use the functionality of the components? I don't know.
What do you think how to handle this?
Additionally there is a branch names
Mogre17.
It's only a short branch of 2010 and the changes were merged to the default branch.
I think it would be a good idea to close that branch, because it can confuse people.