Seeking for a new maintainer

GantZ

22-06-2010 14:48:26

Hello all,

This is not good news i have to announce, i have decided to step down from my role of mogre maintainer. The most active member of the forum should have already notice it, but i have been away from some time now, and since i haven't enough time and dedication to work on mogre, i have take this decision to stop all my activities on the project and it plugins. That don't mean i won't use mogre anymore, but i won't be able to check the forum as much as before. Currently, I'm still working on a personal project using mogre, and that's the only project i could manage to spare some time on aside from my work. I hope to show my progress on this one, and eventually open the source code so that's everyone can benefit of it.

That said, i take advantage of this thread to seek for a new maintainer who's willing to spare some time for the mogre project. Also, even if you don't plan to become a mogre maintainer, but just want to share your work on mogre (like binairies) you can pm me so i can grant you access to the sourceforge and/or mercurial project. you could also make a fork from the actual mogre code and use it as the central repository if you prefer. I will stay available for the next few day to reply to request on this.

I want also to thanks everyone who have / continue to help on this project, and allow it to live despite all the difficulties it could have encountered.

xerios

22-06-2010 16:50:02

Don't tell me that Mogre is getting the same fate as OgreDotNet :(

This is just... sad

koirat

22-06-2010 20:15:14

I'm going to seriously cry. :cry:

Anyway thanks for all the effort when maintaining Mogre.

Beauty

23-06-2010 16:05:40

Hi GantZ,

I'm sad to hear about your decision. :cry:
But I can understand you and it's fine that you tell us your decision.
Thanks for all your work, especially for the MogreNewt effort. This was very important for my university project (sonar simulation for underwater vehicles).


Currently I'm not very ative, but I will stay for the next months, because I still work on my Mogre project.
As a maintainer I wouldn't be a help, because I have no C++ experience. Apart from that I would like to get access to the repositories. So there is still a person who could be asked for write access if somebody in the future wants to maintain or just submit updates. (I think there was a time where we had such a problem. The Mogre father Bekas was on military service for many months and nobody else had SVN write access.)


My opinion is that we should use only the SVN or Mercurial repository with write access. To have 2 parallel repositories is not nice to syncronice and confusing other people, especially newcomers.
I suppose there should be good reasons why Ogre, Mogre and other projects moved to Mercurial. What is the main advantage? (I just want to know - it's no criticism.)


I would be know what kind of Mogre projects you have and had. Maybe with some screenshots. I'm interested.


The old maintainers Bekas and maybe Marioco promised to write to the wiki how to apply the autowrapping process. But if I remember right, nobody did it.
If there is a wrapping guide, please tell me.
If there is nothing about, it would be great, if you make a last big act and show your heirs how to continue this nice project.
Even if these are some dirty notes, it can be much helpful. A quick guide needs maybe 10 up to 30 minutes.
You can do it in the forum (and I copy it to the wiki) or just click here to create a new wiki page called MOGRE Autowrapping Guide.

Beauty

23-06-2010 16:19:01

GantZ, I added you to the hall of fame in the Mogre wiki.
Additionally I added Kwertz for his work on the MogreSDK and smiley80 for his support in forum and his code snippets. Sorry if I forgot important persons - the last months I was not very active.

mstoyke

23-06-2010 22:45:29

Additionally: Even if you aren't a maintainer it would be good when you are a full access admin for the Mogre repository(ies), because GantZ will leave this project soon and it's good to have an active person with full access. When somebody wants to carry on the maintain work, he needs somebody who gives him admin rights. So you would be a useful contact person.

If nobody expects me to be here all the time and you can live with me being too busy for some weeks sometimes to attend to Mogre... I could be one maintainer instead of the maintainer of Mogre. What I mean is, if we have 2 or 3 more people to share the maintainer status with me and take responsibility for some parts of Mogre I could maybe change my mind about not being a maintainer at all.

I could image something like:

- Mogre technical maintainer -> me
-- responsible for the repositories and keeping Mogre up-to-date with latest changes in Ogre

- Mogre documentation maintainer -> Beauty (?)
-- reponsible for the Wiki and other documentation

- Mogre SDK maintainer -> (?)
-- responsible for keeping an installable SDK up-to-date and bundle Mogre, documentation and tutorials/examples

- Mogre addons maintainer -> (?)
-- responsible for managing all addons to Mogre, like Newton, GUIs, bindings to Ogre addons, ...

So I would not be the only person responsible and there is a higher chance that somebody is available for questions even when others are too busy to work on Mogre. Just let me know your opinion about this idea.

P.S.: being maintainer for some parts of Mogre does not mean that you have to do all the work for their part, it's more about who is responsible for something. For example, being the maintainer for Mogre addons, your responsibility is to arrange contributed addons in the repository in a way that they can be compiled without too many problems. It does not mean you have to write all addons yourself.

Spanky

24-06-2010 04:26:57

I wouldn't mind being a partial contributor. I've done some auto wrapping stuff myself and have worked on tweaking the code so it works with other add-ons as well (I lost it in a crash though].

I think the main thing we need to get is a complete guide describing exactly how to generate the 1.7.1 dll out of whatever is in the Mercurial repository. With a simple guide, I would be more than willing to go in and describe more detail about it. I took a stab at it before but I couldn't figure out how to apply the patch properly to the source since it looks like it's an SVN diff but the sources aren't from SVN anymore.

Grantz - do you think you could write up something fairly quickly for us? I know you're leaving because you're pressed for time but it would help us carry on your work greatly.

PS - Thank you SOOOO much for everything you've done. Being on projects like this myself, I know it can really take a toll on you so it has not gone unappreciated what so ever :)

Beauty

24-06-2010 11:07:12

If nobody expects me to be here all the time
In my eyes all active supporters are automaticly maintainers.

On this open source project everybody does what he like to do.
But there is no duty to do something.
Every improvement is welcome - independent of its amount.

So we are happy about everybody who support Mogre as he like and can.
I think it's a good idea to have contact persons for different things.
Also I think the most important thing is to keep up to date the Mogre core.
Other things are also important, but has lower priority.
I suppose there will ever be some gaps. Especially for the documentation parts. This is one point where I did much effort (more than 1000 wiki edits).

- Mogre documentation maintainer -> Beauty (?)
-- reponsible for the Wiki and other documentation

I like to share my experiences and to copy important information from forum threads to the wiki. Often it's a pain to search for details which are hidden in large forum threads. On the other side I would like to update some things (e.g. the current Mogre depencies), but I don't know the current state or details. So sometimes I ask other people and some of them feed the wiki.

- Mogre SDK maintainer -> (?)
-- responsible for keeping an installable SDK up-to-date and bundle Mogre, documentation and tutorials/examples

Kwertz is the most important person. He created a new and better SDK, including a useful setup routine. Good content and update support was created by smiley80. I just added a few ideas, test results and tiny InnoSetup improvements.

- Mogre addons maintainer -> (?)
-- responsible for managing all addons to Mogre, like Newton, GUIs, bindings to Ogre addons, ...

In the past they were be maintained mostly by its creators and I think this will go on like this (hopefully that the authors give long time support ;-). Additionally improvements can be added by others. For one person it would be much work. And when somebody doesn't use some add-ons there is less interest to maintain them.
Important is to have it's source code in a repository and somebody is able to give write access to interested people.

Beauty

24-06-2010 11:38:33

Related to source code maintaining - it's confusing that there are different places.

Mogre source code
* http://mogre.svn.sourceforge.net (SVN)
* http://bitbucket.org/gantz/mogre/src (Mercurial)
* http://bitbucket.org/mstoyke (Mercurial)

And the Mogre SDK content
* http://code.google.com/p/mogresdk (SVN with binaries, add-ons, installer script, etc.)

There was a discussion about merging the Mogre core and SDK code. In this case were some good arguments to have them seperated. (ok, there were also opposite arguments)
It's ok, when this issue is clearly documentated (e.g. at the Mogre page in wiki or the repository homepages)


But it's bad to have a splitted core place.

My proposal:

* set mogre.svn.sourceforge.net to read-only (and add a note to the project overview page)

* create a Mercurial repository which is independent of a person
. . . . . means: move the content of bitbucket.org/gantz/mogre/src to bitbucket.org/mogre

* add the content of bitbucket.org/mstoyke to bitbucket.org/mogre

* if needed: make a fork for the VS 2010 / .NET 4.0 version?
. . . . . I don't know the amount of code differences, but it would be good when it's easy to compile both versions. Currently I would still support VS 2008, because not everybody still has VS 2010 (pro version needs money) and some add-ons currently doesn't work (e.g. Newton - the reason is not the wrapper - they have some problems with the Newton core library under VS 2010)

* when we don't make a fork for VS 2010 / .NET 4.0 then it would be good to have a note in the guide Building MOGRE 1.7 from source what to set up for this and that version. Additionally it would be good to provide both binarie versions as download.

* I think currently the MogreSDK should still stay on VS 2008 / .NET 2.0 state, because the main target are newcomers who needs an easy installation and wants to play with the samples. With VS 2008 not all samples and used add-ons works. Also it would be a bigger effort to update all the content (including installer script files).

mstoyke

24-06-2010 12:11:38

I created an user "mogre" at bitbucket and I also created two repositories "Mogre" and "MogreAddons" there. I think it's best to maintain one solution file for VS2010 with different configurations. VS2010 can target any framework from 2.0 up to 4.0, so I would create different configurations to create all Mogre version out of one solution file.

I want to do any active development for Mogre in the main branch "default" and then create different branches in the repository for different Ogre versions. Something like "Mogre16", "Mogre17", "MogreTrunk", ...

Maybe we can keep a version of Mogre up-to-date with the latest bleeding edge Ogre version that is currently in development. That would allow us to quickly provide a working wrapper once the new Ogre version (1.8) will be released.

All addons and contributions should be in the MogreAddons repository and building them should depend on the Mogre SDK and not the Mogre wrapper sourcecode. Tutorials and example code/projects should be kept in the Mogre or MogreAddons repository depending on what they want to demonstrate. So the Mogre demos will be in the Mogre repository, but demos that show how to use addons like e.g. MOIS or FreeSL will be in the MogreAddons repository.

There should be two SDK installers, one targeting .NET2/VS2008 and one targeting .NET4/VS2010.

The goal is to have only one official repository for Mogre to stop confusion.

GantZ

24-06-2010 13:38:05

I would be know what kind of Mogre projects you have and had. Maybe with some screenshots. I'm interested.

Maybe one day, i will be able to show something :) but for the moment, it still need some more work

If there is a wrapping guide, please tell me.
If there is nothing about, it would be great, if you make a last big act and show your heirs how to continue this nice project.
Even if these are some dirty notes, it can be much helpful. A quick guide needs maybe 10 up to 30 minutes.


About wrapping note, most of the process is in the mogre developpement thread, but i could gather the note in a step by step guide to wrap ogre from scratch. i will try to find some time this week end to make it. i could also write something about wrapping in a general way, i got some useful note about it.

About repository, everything take place in the mercurial repository (and it fork). The mogre svn repo on sourceforge is already read-only. I agree that having a single repo for everything could be better in the end, at first, i think that i would help to have different place since that maintainer were not the same, but in the end it's confusing for the users, and easier to manage if there is one only place.

But rest assured, i won't disappear in thin air :) , so if you need to get some rights, just ask. i have already added mstoyke on sourceforge so he can release his files here.

Otherwise, good to know that people want to keep mogre maintained, thank you all :)

Beauty

24-06-2010 14:40:37

I created an user "mogre" at bitbucket and I also created two repositories "Mogre" and "MogreAddons" there.
Ok, the first step is done.
Thanks for your interest and effort.

I think it's best to maintain one solution file for VS2010 with different configurations. VS2010 can target any framework from 2.0 up to 4.0, so I would create different configurations to create all Mogre version out of one solution file.
Basically right. But currently I'm still afraid that not all users still not have VS 2010. (e.g. on my working place wee need some time to get the permission/money to buy it)
I suppose converting VS 2008 projects to VS 2010 is possible, but downwards not easy. On the other hand VS 2010 is the future and the maintainers doesn't want to keep track of 2 versions.
I hope the problems with Newton and VS 2010 will be solved.


I want to do any active development for Mogre in the main branch "default" and then create different branches in the repository for different Ogre versions. Something like "Mogre16", "Mogre17", "MogreTrunk", ...
Generally it's nice to have branches, but it's more work to maintain.
Instead of Mogre17 I just would use the trunk. When Ogre 1.8 is released, then it's a good time to make a fork.
Currently I more worry about the .NET 2.0 / 4.0 differences. Is there a need to have different source code? (independent of VS project properties) I suppose at least the linked dll files are different.
To have different repositories for .NET 2.0 and 4.0 would be more difficult to maintain and synchronize.
I don't know how to handle this, I just added my thoughts.


All addons and contributions should be in the MogreAddons repository and building them should depend on the Mogre SDK and not the Mogre wrapper sourcecode. Tutorials and example code/projects should be kept in the Mogre or MogreAddons repository depending on what they want to demonstrate. So the Mogre demos will be in the Mogre repository, but demos that show how to use addons like e.g. MOIS or FreeSL will be in the MogreAddons repository.
I'm not shure about how to seperate all the Mogre stuff.
Useful would be to have a MogreAddons repository, where different developers have the possibility to maintain her own add-on projects at an "official Mogre place". Good would be to have seperated revision numbers for each add-on. So it's better to keep track in the history. (I suppose this is right, but I'm not shure, because I didn't yet work much with repositories.)

Related to the SDK I worry a little bit. The main purpose was to have a place which contains everything, which is needed to build the installer. E.g. binary files, depency checkers, demos, ressource files etc.

For development of add-ons the MogreSDK repository wasn't used. We just added the binary files after add-on updates. An advantage is that the SDK contains stable versions. When we mix add-on development and SDK then I'm afraid that an unstable/unready dll file flush into the SDK setup. Also a demo could get incompatible after an add-on update.
The word SDK means development kit for the end user - not for the developer of an add-on. (maybe this was not clear by the name.)

So what's about to have 3 repositories?
* Mogre
* MogreAddons
* MogreSDK


There should be two SDK installers, one targeting .NET2/VS2008 and one targeting .NET4/VS2010.
This would be good for the end users. But it needs much effort to convert everything to the new environment (including installer routines, tests, etc.). Who will do the job to convert all parts of the SDK? Also it's more work to maintain 2 variants. Anyway - we are happy that we have a well SDK with installer.
Your idea is nice, but you know about the problem to find maintaining people. (I hope I don't disturb you with my negativ sounding words.)


The goal is to have only one official repository for Mogre to stop confusion.
I think it's important to have a good way for further Mogre development. To have one place is good.
Most important is that the users see where are the right places and what's the differences (e.g. diff between Mogre and MogreSDK).
Outdated repositories should be read-only and contain a good visible outdated note.

Before we move the SDK content to a new home I would ask Kwertz for his opinion. He is the main creator/maintainer of the SDK.

Beauty

24-06-2010 14:46:57

I would be know what kind of Mogre projects you have and had. Maybe with some screenshots. I'm interested.
Maybe one day, i will be able to show something :) but for the moment, it still need some more work

Do you create a game or an editor or a research project or something else? Just to get an idea.
Did you create more than one project? Only private or also for your working place?


About wrapping note, most of the process is in the mogre developpement thread, but i could gather the note in a step by step guide to wrap ogre from scratch. i will try to find some time this week end to make it. i could also write something about wrapping in a general way, i got some useful note about it.
Ok, then I want to search for informations in this thread. (but not this week)
But a guide would be great!

You can also add me as maintainer to sourceforge. Then I can update the summary page and add notes for the new place.

mstoyke

24-06-2010 15:25:22

Basically right. But currently I'm still afraid that not all users still not have VS 2010. (e.g. on my working place wee need some time to get the permission/money to buy it)
I suppose converting VS 2008 projects to VS 2010 is possible, but downwards not easy. On the other hand VS 2010 is the future and the maintainers doesn't want to keep track of 2 versions.


Using VS2010 should not be a problem, for the Mogre version that is targeting .NET 2.0 it's only necessary to compile Mogre. The compiled binaries can be used with VS2008 or VS2010. To compile Mogre, the free VS2010 Express version is all you need.

Generally it's nice to have branches, but it's more work to maintain.
Instead of Mogre17 I just would use the trunk. When Ogre 1.8 is released, then it's a good time to make a fork.


It's best to maintain branches for version that are supposed to be stable and only receive bugfixes. So development will occur in trunk while releases will be maintained in branches. Mercurial encourages this development style, because it is very easy to maintain different branches and merge changes between them. If Mogre would still use SVN I would agree with you that branches could lead our way directly to coders hell :)

Currently I more worry about the .NET 2.0 / 4.0 differences. Is there a need to have different source code? (independent of VS project properties) I suppose at least the linked dll files are different.
To have different repositories for .NET 2.0 and 4.0 would be more difficult to maintain and synchronize.
I don't know how to handle this, I just added my thoughts.


All version will use the same codebase to compile. There were only problems in converting VS2008 version to compile with VS2010 that could be fixed by "obeying" some stricter compiler rules. A version that compiles with 2010 will also compile with 2008, only the other way around there might be problems.

For development of add-ons the MogreSDK repository wasn't used. We just added the binary files after add-on updates. An advantage is that the SDK contains stable versions. When we mix add-on development and SDK then I'm afraid that an unstable/unready dll file flush into the SDK setup. Also a demo could get incompatible after an add-on update.
The word SDK means development kit for the end user - not for the developer of an add-on. (maybe this was not clear by the name.)


I think there is no difference between what you call end user and a developer of addons. No matter if somebody created an addon or a game based on Mogre, either way they need a stable library to link to. By making all addons compile with an installed Mogre SDK it should be easier to maintain stable versions with a defined dependency (like for example saying: FreeSL 1.1 depends on Mogre SDK 1.7.1). Nobody will have to worry about finding the right version of Mogre in the repository, just install the SDK and compile the addons you need.

I'm not talking about the SDK repository for addons, I want them to depend on the installed binary release of Mogre...

So what's about to have 3 repositories?
* Mogre
* MogreAddons
* MogreSDK

...and...
Before we move the SDK content to a new home I would ask Kwertz for his opinion. He is the main creator/maintainer of the SDK.

The only reason I didn't create a MogreSDK repository yet is, I first need to talk to the current SDK maintainer (Kwertz in this case) to ask him if we should move the repository to Mercurial at bitbucket.

The new repository structure could be something like:
Mogre
is used to compile binaries and create dependencies for
MogreSDK
which will be installed and used as dependency for all projects in
MogreAddons
which might get their own installers for compiled binaries if we can find somebody to maintain the installers...

Beauty

24-06-2010 16:33:36

Mercurial encourages this development style, because it is very easy to maintain different branches and merge changes between them. If Mogre would still use SVN I would agree with you that branches could lead our way directly to coders hell :)
I never used it, just read about that different projects (e.g. open office) use it.
Now I know the advantage of Mercurial. I installed the Tortoise client and will see how it works.


On my working place I used SVN and a team mate mixed add-ons with the main application (inside the SVN).
The result: He developed his add-ons, but often they were not working (because he paused the work) or changed things in the API. Then I had problems to compile and use the main application. So I decided to just link his stable binaries.
Ok, this is just my personal experience. Because of this I'm a little bit afraid.

I have no knowledge of C++ and had problems to compile Mogre or other stuff (2 years ago). So I just used the compiled dll files, which were offered by the maintainers.
Related to the SDK I thought it's better for newcomers to just have the binaries.
At first they want to install the SDK (including depencies) and play around with demos.
If there are maybe compiler errors or different things have to be compiled, maybe they are confused or think what a shit. They don't care about the add-ons souce code. They just want to use it.
On the other hand - if it works fine, it could be done as you said.
In the current SDK the samples will be build on the computer where the SDK in installed. (But not the add-ons or even Mogre.)

Maybe it could be done like this:
In the SDK repository are 2 different scripts.
One for building the sources (done by a maintainer).
And an other for building the setup file, using the sources which were compiled before.

I suppose your idea is to have an SDK which is a plain Mogre installer without add-ons. But in this case we couldn't provide several demos (physics, GUI, Hydrax water, etc.).

Well, I'm not shure about how to split the projects. Maybe some of my thoughts are wrong.
I hope some other people tell his opinion and ideas.
Kwertz and smiley80 I invated to this discussion.

But thanks mstoyke for the time you still spend yet.

mstoyke

24-06-2010 16:54:07

I suppose your idea is to have an SDK which is a plain Mogre installer without add-ons. But in this case we couldn't provide several demos (physics, GUI, Hydrax water, etc.).

I have to think about it again. Maybe it's better, like you said, to have everything (Mogre, addons, tutorials, examples) installed from one complete installer. In that case it's better to just make MogreAddons depend on the compiled binaries from Mogre and then compile everything and use it as dependency for creating the complete Mogre SDK installer.

kwertz

24-06-2010 17:36:09

As proposed by Beauty, I will keep maintaining the SDK, its installer and tools (like the dependency checker and the sample browser etc.). Also I have gained some skills at programming in C++ last 3 months. So, maybe I could help mstoyke a bit wrapping the code - provided GantZ gives me some instructions so that I know what I have to do...

Someone also mentioned to exclude the add-ons from the SDK. Let's do it like this: let's just make them and the corresponding demos optional at installation-time, so that the user may choose whether to install particular add-ons or not. This way it's more user-friendly.

The only reason I didn't create a MogreSDK repository yet is, I first need to talk to the current SDK maintainer (Kwertz in this case) to ask him if we should move the repository to Mercurial at bitbucket.

The new repository structure could be something like:
Mogre
is used to compile binaries and create dependencies for
MogreSDK
which will be installed and used as dependency for all projects in
MogreAddons
which might get their own installers for compiled binaries if we can find somebody to maintain the installers...

I think it's good to divide MOGRE and its surroundings into three separate sections. So you are free to do it. But please inform me once that is done.

Another problem that should be addressed is documentation, since MOGRE is seriously lacking of good documentation.
For example once the user installs the SDK there should be a quick start guide and a guide to do common things with MOGRE like converting a Mogre.Image to a System.Drawing.Image and vice versa.
Also there could be an automatically generated HTML documentation like that that is output by doxygen. I propose Beauty to do this since she's very talented at writing.

Another fine idea: I could code a SDK maintenance utility combining all common maintenance tasks like building the SDK from a fresh compilation of MOGRE and so on.
A new all-in-one smart autowrapper tool would also be useful for future development.

Additionally I like Marioko's vision to create a new and better MOGRE from scratch. See here: viewtopic.php?p=38113.

smiley80

24-06-2010 18:38:54


For example once the user installs the SDK there should be a quick start guide and a guide to do common things with MOGRE like converting a Mogre.Image to a System.Drawing.Image and vice versa.

Some time ago, I've converted several wiki articles and snippets from the forum (DataStream to MemoryStream, System.Drawing.Image to Mogre.Image, Line3D, ManualObject2D but also some fringe stuff) to an extension methods library. Any interest in putting that into the SDK?


Also there could be an automatically generated HTML documentation like that that is output by doxygen. I propose Beauty to do this since she's very talented at writing.

You can already generate that from the XMLDoc file with Sandcastle. I'm currently looking into improving the xml converter in regard of properties.

kwertz

24-06-2010 18:56:37

Some time ago, I've converted several wiki articles and snippets from the forum (DataStream to MemoryStream, System.Drawing.Image to Mogre.Image, Line3D, ManualObject2D but also some fringe stuff) to an extension methods library. Any interest in putting that into the SDK?

Yes, definitively. Could you post the download link so that I can review it?

You can already generate that from the XMLDoc file with Sandcastle. I'm currently looking into improving the xml converter in regard of properties.
Thanks for this hint, I will take a look at Sandcastle.

mstoyke

24-06-2010 22:18:04

So I assume that I can update our maintainer list as follows:
- Mogre technical maintainer -> mstoyke
- Mogre documentation maintainer -> Beauty
- Mogre SDK maintainer -> kwertz
- Mogre addons maintainer -> (?)


As proposed by Beauty, I will keep maintaining the SDK, its installer and tools (like the dependency checker and the sample browser etc.). Also I have gained some skills at programming in C++ last 3 months. So, maybe I could help mstoyke a bit wrapping the code - provided GantZ gives me some instructions so that I know what I have to do...

It's good to see that you want to keep updating the SDK. I have updated the maintainer list accordingly.

Someone also mentioned to exclude the add-ons from the SDK. Let's do it like this: let's just make them and the corresponding demos optional at installation-time, so that the user may choose whether to install particular add-ons or not. This way it's more user-friendly.

I was first thinking about separating the SDK and the addons/samples into two installers. But I can now see the advantage of just having one installer for everything and making some parts of it optional.

I think it's good to divide MOGRE and its surroundings into three separate sections. So you are free to do it. But please inform me once that is done.

I sure will. Only question is, do you want to keep the SDK repository at google code or should we move it to mercurial like I proposed in one of my last posts.

Another problem that should be addressed is documentation, since MOGRE is seriously lacking of good documentation.
For example once the user installs the SDK there should be a quick start guide and a guide to do common things with MOGRE like converting a Mogre.Image to a System.Drawing.Image and vice versa.
Also there could be an automatically generated HTML documentation like that that is output by doxygen. I propose Beauty to do this since she's very talented at writing.


Even if Beauty can't write all documentation, it would be good to have somebody to collect all contributions and wiki updates and make sure that everything can be found easily. As for the API documentation, we should focus on the differences between Ogre and Mogre API. I think that most functions can just be understood from reading the (very good) Ogre documentation.

Another fine idea: I could code a SDK maintenance utility combining all common maintenance tasks like building the SDK from a fresh compilation of MOGRE and so on.

That would be a good idea indeed. I usually create makefiles in my projects for such tasks. But if you want to write a tool specific to this task it might be a better solution that will fit your needs perfectly.

A new all-in-one smart autowrapper tool would also be useful for future development.

I don't see any problems with the autowrapper at the moment. It might not be the best solution because it needs more than just a click on a button to create the wrapper code, but it gets the job done and is, in my opinion, very easy to understand and extend.

Additionally I like Marioko's vision to create a new and better MOGRE from scratch. See here: viewtopic.php?p=38113.

I think the only valid reason for creating everything new from scratch is to change the wrapper from C++/CLI to P/Invoke to make it compatible with Mono to support other platforms than Windows. I used and modified many different wrappers in the past, from simple C++/CLI wrappers to swig-based wrappers for commercial software and libraries that needed to support Windows and Linux/Mono.
In my opinion Mogre has a very clean structure and is incredible stable in most cases. We should not change a running system, but focus on fixing bugs in the codebase now to create a stable release as soon as possible.

smiley80

24-06-2010 22:35:24


Yes, definitively. Could you post the download link so that I can review it?

See attached file.
Documentation isn't complete and credits to the original authors are missing (mainly for the forum post + MMOC based methods).
And I haven't tested it against the current Mogre version.

manski

25-06-2010 08:43:09

I created an user "mogre" at bitbucket

I just had the same idea. But you were faster. However, I'd like to see that we use bitbucket's issue tracker for Mogre issues. I know currently they are scattered throughout the forum but I doubt that this method is very user-/maintainer-friendly. Having actual bug reports (and feautre requests) in a single place (like every big project has) would be a great benefit for both users and mainainers. (This way one can have a quick glimpse of what still needs to be fixed in Mogre.)

Also I'm not sure how you'd thought to manage access to the Mercurial repository but I think it would be best to have more than one person to have access to the "mogre" user on bitbucket. This could be accomplished by giving the password for the "mogre" account to all Mogre maintainers. Moreover you could create a "shared" email adress for all Mogre maintainers (which then will forward each mail sent there to the maintainers' email adresses) and use this email adress for the mogre account on bitbucket. (I've created "mogre.team _at_ googlemail _dot_ com" for that purpose before reading this thread. You could use it or if not, I will delete it again.) This would reduce the likelyhood of noone having access to the mogre repository anymore sometime in the future. Just a thought.

mstoyke

25-06-2010 10:54:35

However, I'd like to see that we use bitbucket's issue tracker for Mogre issues. I know currently they are scattered throughout the forum but I doubt that this method is very user-/maintainer-friendly. Having actual bug reports (and feautre requests) in a single place (like every big project has) would be a great benefit for both users and mainainers. (This way one can have a quick glimpse of what still needs to be fixed in Mogre.)

You're right, Mogre lacks an issue tracker where bugs and feature requests can reported. I can enable the tracker at bitbucket and we should try it for some time to see how well it works.

Also I'm not sure how you'd thought to manage access to the Mercurial repository but I think it would be best to have more than one person to have access to the "mogre" user on bitbucket. This could be accomplished by giving the password for the "mogre" account to all Mogre maintainers. Moreover you could create a "shared" email adress for all Mogre maintainers (which then will forward each mail sent there to the maintainers' email adresses) and use this email adress for the mogre account on bitbucket. (I've created "mogre.team _at_ googlemail _dot_ com" for that purpose before reading this thread. You could use it or if not, I will delete it again.) This would reduce the likelyhood of noone having access to the mogre repository anymore sometime in the future. Just a thought.

It's actually very easy for me to give write permissions to other people if they have an account at bitbucket. I think the best way to handle this is to give admin permissions for the repositories to the other maintainers and write permissions to any supporter and contributor.

manski

25-06-2010 10:59:36

You're right, Mogre lacks an issue tracker where bugs and feature requests can reported. I can enable the tracker at bitbucket and we should try it for some time to see how well it works.

This would be very nice (and don't forget to add the link to the wiki). But then you should also migrate your two repositories (mstoyke-ogre and mstoyke-mogre) as well as gantz' repository to the Mogre account. Otherwise we might end up with yet another Mogre site to confuse newbies like me even more ;)

It's actually very easy for me to give write permissions to other people if they have an account at bitbucket. I think the best way to handle this is to give admin permissions for the repositories to the other maintainers and write permissions to any supporter and contributor.

Yes, if this works this would be preferable.

mstoyke

25-06-2010 11:12:40

This would be very nice (and don't forget to add the link to the wiki). But then you should also migrate your two repositories (mstoyke-ogre and mstoyke-mogre) as well as gantz' repository to the Mogre account. Otherwise we might end up with yet another Mogre site to confuse newbies like me even more ;)

All repositories will soon be merged into the new bitbucket/mogre repositories. Then I will delete my old mstoyke-ogre and mstoyke-mogre repositories to avoid confusion about them.
I will also not keep any clone of the ogre repository, it would just cause more confusion. Instead I will make sure that there are valid patch/diff files to apply to the sources from the original ogre repository.

manski

25-06-2010 11:16:36

I will also not keep any clone of the ogre repository, it would just cause more confusion.

There goes the "easy build" ;) But then the building wiki page should be updated.

Ah - and here is my (uncleaned) "how-to-build-mogre.txt" file. Maybe its of some help:


Please verify this!

- Download DirectX SDK (tested with DirectX SDK June 2010; no longer support for Visual Studio 2005; http://msdn.microsoft.com/en-us/directx/aa937788.aspx)
- Install Cygwin for using "patch" (found under "Utils/Patch" in the installer) or use TortoiseSVN's "Apply patch" functionality
- Install CMake (http://www.cmake.org)

- Download boost (www.boost.org). Compile and install it.
$ cd {BoostDir}
$ bootstrap
$ bjam
- Set the environment variables BOOST_INCLUDE_DIRECTORY
(e.g. C:\boost\include\boost-1_42) and BOOST_LIBRARY_DIRECTORY
(e.g. C:\boost\lib).
=> not anymore: In Cmake specify the boost directory (containing the folders "boost", "lib", ...)
for "Boost_INCLUDE_DIR" in the advanced view.
- Download Ogre Dependencies and extract them, e.g.
http://sf.net/projects/ogre/files/ogre-dependencies-vc%2B%2B/1.7
into Main/OgreSrc/Dependencies. Compile the Dependencies.
- Clone ogre sources, branch 1.7 into Main/OgreSrc/ogre.
See Main/OgreSrc/readme.txt for more.
- Patch Ogre files by applying "Main/Ogre Patches/Mogre.patch"
(don't apply the mercurial patch)
$ cd Main/OgreSrc/ogre
$ c:\cygwin\bin\patch -p0 <"..\..\Ogre Patches\Mogre.patch"
- Close all visual studio instances (otherwise CMake will spit out errors).
- Start CMake to generate Ogre build files. Make sure you have
OGRE_CONFIG_ENABLE_PVRTC switched ON and
OGRE_CONFIG_CONTAINERS_USE_CUSTOM_ALLOCATOR switched OFF. (both only in "Advanced View")
Target
Main/OgreSrc/build as output directory.
-> Don't try to compile the project yet.
-> Open Solution and check whether the project "RenderSystem_Direct3D9" is included
(may be missing due to installation errors of the directx sdk)
- execute Codegen/cpp2java/build.bat (from within Codegen/cpp2java)
- Compile AutoWrap (Codegen/AutoWrap/AutoWrap.sln or ...AutoWrap_vs2010.sln)
- Run AutoWrap and click "Produce".
- Compile Ogre. If you get the error "missing mogre.lib",
make sure that in CLRConfig.h it is "#define LINK_TO_MOGRE 0"
- Compile Mogre (either Main/Mogre_vc9.sln or Main/Mogre_vs2010.sln)
- Change in Main/OgreSrc/ogre/OgreMain/include/CLRConfig.h the define
to "#define LINK_TO_MOGRE 1"
- Compile Ogre again (no need for a full rebuild)

TODO:
* What's on upgrade? Which steps need to be redone? Which output folders must be deleted?
* Does the debug version of Mogre automatically use the debug version of Ogre? -> yes, at least Ogre_d.lib
* What's this "LINK_TO_OGRE" directive doing?

Beauty

25-06-2010 15:03:00

Let's do it like this: let's just make them and the corresponding demos optional at installation-time, so that the user may choose whether to install particular add-ons or not. This way it's more user-friendly.

I'm not shure if this is good for the maintainers. The add-ons use a shared ressources folder. So we would need to check, which (of the many files) are used from which add-on and what by the main part. Also in future the shared ressource access can change and there would be a need to update it.
With more options the installer script would be more complex. More problems could happen and different settings have to be checked.
I don't want to say no - I just want to point to the increasing effort for our "Starter Kit".

If you decide to give more options - maybe we offer this:
* full package (like the current SDK)
* minimum installation (check/update depencies, install core binaries and one simple demo) - this could be good for users who have a very slow internet connection or for people who just want to get the current core libraries.

In both cases I would add this to the installer script:
When the installation process is ready - a simple demo should be started automatically.
It could show the mesh Sinbad (Ogre mascot) including animation (like this video). Additionally show the text: "The installation was successful". Maybe the demo is still precompiled. Just to show the user, that the installation process was fine.


Another problem that should be addressed is documentation, since MOGRE is seriously lacking of good documentation.
For example once the user installs the SDK there should be a quick start guide and a guide to do common things with MOGRE like converting a Mogre.Image to a System.Drawing.Image and vice versa.
Also there could be an automatically generated HTML documentation like that that is output by doxygen. I propose Beauty to do this since she's very talented at writing.

Yes, documentation is important. In general there are many documentation gaps in the wiki. Not only Mogre related.
I think a good step would be to check all Mogre tutorials, at least the basic ones. I'm shure that there has to do some updates. At least the depencies. The basic tutorials are similar to a quick start guide.


converting a Mogre.Image to a System.Drawing.Image
I suppose this example is not very interesting for beginners. I never needed this. We don't know what beginners want to do. Everybody does other things.
But it would be a good idea to put such snippets to the wiki.
Tiny snippets (like your example) can be inserted to the page Mogre HOWTO's and Snippets.
When somebody wants to offer a bigger snippet, he can create a new wiki page for that and put a link from Mogre HOWTO's and Snippets to the new page.

automatically generated HTML documentation
You mean the API?
For this smiley80 still created a tool, which creates the file CViewVR.xml and at least for one other Mogre library. I suppose smiley80 did publish it somewhere, but I can't remember the place. Maybe a good target place for this could be the MogreSDK repository?


Another fine idea: I could code a SDK maintenance utility combining all common maintenance tasks like building the SDK from a fresh compilation of MOGRE and so on.
Helpful tiny scripts can be nice and useful. Maybe they could be started one by one.
A script for doing "everything" can be well, but there is a bigger need to update it when something changes. Also the error management would be more complicated (if something happens which wasn't expected).
Instead of a "monster script" I would prefere to explain the steps on a wiki page.
Ok, I can't talk about much, because I never looked to Mogre build processes and don't know what's happens there.

A new all-in-one smart autowrapper tool would also be useful for future development.
Bekas (the author of Mogre) wrote, that his wrapper was just a dirty quick hack. If he would do the same job again, then he would do it much more better. But I don't know which details he mean. And I don't know if it's much work. But I think - our people had big problems to update the current wrapper code from Mogre 1.4 to 1.5. Maybe it will be more complex to start over for a new wrapper. Also - would the current Mogre applications be compatible to the new wrapper output?

Additionally I like Marioko's vision to create a new and better MOGRE from scratch. See here: viewtopic.php?p=38113.
I can't talk about this. I have no C++ experience. When I tried to update the MogreNewt wrapper to my own I had much trouble. The lines are looking easy, but it was hard. For example I didn't know for which wrapped function I need * or ^ (managed/unmanaged pointers).
Marioco was working on a tool for autowrapping add-ons. Maybe this was the same project for autowrapping Mogre, too. He is out of the project, but if you really want to do such a job - we could contact him and ask for his code. He never published it, because it was not ready. (......... just in the moment I wrote Marioce a message and invated him to discuss here, too)


Some time ago, I've converted several wiki articles and snippets from the forum (DataStream to MemoryStream, System.Drawing.Image to Mogre.Image, Line3D, ManualObject2D but also some fringe stuff) to an extension methods library. Any interest in putting that into the SDK?
This sounds useful. You created much good stuff! I see it in different posts. Somebody ask and you pick something out of your wizzard hut.
Good would be to have a wiki page for it for documentation purpose. Additionally it would be important to have XML comments in your methods.


By the way - I remember the project MogreQuickStart. I never used it, but maybe this could be interesting for the SDK??
I just want to point to this possibility.
MogreQuickStart is a .NET class written in Visual Basic 2008. It's goal is to provide a quick entry point to easily write Mogre applications. I developped it for myself to use it in my project (KSEditor), but everyone can use it. It takes in input as an OSM file to load.
http://www.ogre3d.org/tikiwiki/MogreQuickStart


... oh my good now I see there are so much answers here. I'm happy about the talk, although I don't have much time these days. So maybe I don't answer all the time.



I was first thinking about separating the SDK and the addons/samples into two installers. But I can now see the advantage of just having one installer for everything and making some parts of it optional.
Look aside from depency downloads like DirectX, I'm a little bit unfriendly to "online-installers". I have many setup files on my hard disk and I don't like installers "without content" very much. One reason is - for 2 installations I need to download the content twice. An other reason - of the installer wants to download something, maybe the content is not available anymore (or are replaced by newer, but incompatible files).
Ok, online installers also advantages. It's just my personal view.
The optional depency download inside the current SDK installer is fine. One point for you.



do you want to keep the SDK repository at google code or should we move it to mercurial like I proposed in one of my last posts.
If we spit the SDK content, we could do this:
Keep the google SVN (read-only) for lookback / comparison if something doesn't work in the new structure.



Even if Beauty can't write all documentation, it would be good to have somebody to collect all contributions and wiki updates and make sure that everything can be found easily.
This was my daily job for a long time. Now I'm not very active, but this could change again :wink:

As for the API documentation, we should focus on the differences between Ogre and Mogre API. I think that most functions can just be understood from reading the (very good) Ogre documentation.
Normally it was fine to just look to the Ogre API. The Mogre members are mostly similar.
Additionally classes are still listed in the wiki (page MOGRE pure .NET classes).



I think the only valid reason for creating everything new from scratch is to change the wrapper from C++/CLI to P/Invoke to make it compatible with Mono to support other platforms than Windows. I used and modified many different wrappers in the past, from simple C++/CLI wrappers to swig-based wrappers for commercial software and libraries that needed to support Windows and Linux/Mono.
In my opinion Mogre has a very clean structure and is incredible stable in most cases. We should not change a running system, but focus on fixing bugs in the codebase now to create a stable release as soon as possible.

Very good words. Also it's great to hear this assessment from somebody who has much experience with it.
If there is any real plan to create a P/Invoke wrapper - user boyamer wrote a C# wrapper by hand for his
Alimer Game Engine. He could be asked if somethimes this job is in progress.
User Wolfmanfx created an autowrapper by SWIG using P/invoke (similar to OgreDotNet). I suppose he didn't publish it.
About one year ago there was also a group of people offering help in revive the OgreDotNet wrapper method (by SWIG). The discussion was in the thread Mogre and OgreDotNet -- combine forces?

Currently I would say a new autowrapper is no important focus.
I just wanted to let you know about interesting people. So you have contact persons for further plans :wink:


I think it would be best to have more than one person to have access to the "mogre" user on bitbucket. This could be accomplished by giving the password for the "mogre" account to all Mogre maintainers.

Nice to see you here, maski :)
Yes, this is one purpose of a public repository, which is not bind to a special person. We had such a problem about 2 years in the past. The only admin was not reachable for months. A mailing list could be interesting, but I don't know if there will come e-mails. One problem could cause if the mail account dies or nobody has access. How is bitbucket managed? On googlecode.com you can add several admins with their own e-mail address.


But then the building wiki page should be updated.
Yesterday mystoyke created a new page in the wiki: Building MOGRE 1.7 from source
The most important things are inside there. More he wants to add.


What in hell ... I needed more than 2 hours for just one post. It's huge. But it's for a good aim 8)


By the way - does somebody has experience with the Axiom engine? It's a full C# port of Ogre and works on Mono. The last update was March 2010. So it's still not outdated.
Is the usage very different to Mogre? If not, maybe there is some stuff we could adopt (e.g. demos).

manski

25-06-2010 15:09:49

By the way - does somebody has experience with the Axiom engine? It's a full C# port of Ogre and works on Mono. The last update was March 2010. So it's still not outdated. Is the usage very different to Mogre? If not, maybe there is some stuff we could adopt (e.g. demos).

Thanks for the link. Maybe I will give it a try.

Beauty

25-06-2010 15:17:49

Thanks for the link. Maybe I will give it a try.
I hope you will not run away :oops:
But even if so (it's your free choice), please give us a feedback later.

manski

25-06-2010 15:26:33

I hope you will not run away :oops:

This won't happen so fast as there are currently other things I'm trying to get done. ;)

Beauty

02-07-2010 18:47:36

The discussion related to the new wrapper I moved to the thread idea: new C# wrapper which supports Linux, MacOS, etc.
Please continue this theme there.

mstoyke

13-07-2010 11:54:35

The current list of maintainers is updated as follows:

  1. Mogre technical maintainer -> mstoyke[/*:m]
  2. Mogre documentation maintainer -> Beauty[/*:m]
  3. Mogre SDK maintainer -> kwertz
    [/*:m]
  4. Mogre addons maintainers:
    1. MogreFreeSL -> koirat, materialDefender[/*:m]
    2. other addons -> (?)[/*:m][/list:u][/*:m][/list:u]