Glue Editor goes open source

Its been a while since I've had time to work on my Glue Scene Editor for Ogre and I feel like it's going to waste just sitting around with so much potential. So I've decided to upload the source code to bitbucket in case anyone else wants to take over development or whatever else the source code might be useful for.

https://bitbucket.org/glue/glueeditor

It should build and run out of the box. All of the dependencies are included. The website and forums (in my sig) are still active and I'll be around to respond to any questions. Certainly, if you are going to do something with it I'd love to be kept in the loop It should be a good foundation for some other kind of editor.

Thanks for sharing your code with the community.
Even if nobody asked for the code now, it could be very useful for people who use it in the future.

The Ogre wiki page is only about the Light version.
As far as I know, you published your first version of the editor, which contains several features.
Later you re-wrote your (whole?) editor with less features, but with a better internal design.
I think both versions are useful.
It would be nice if you publish a comparison to the wiki page (and/or your website).

In the wiki page I updated the See also section now.
I added a link to this new forum topic.
Also I restructured the old links for a better overview.

Even if nobody asked for the code now, it could be very useful for people who use it in the future.

I've had a couple of people ask for the code. I don't know if they are still interested but it can't hurt to have it available. Some of the code for rendering in multiple viewports with solid colour wireframe mode is particularly interesting. It proved to be a challenge when I put it together.

As far as I know, you published your first version of the editor, which contains several features.
Later you re-wrote your (whole?) editor with less features, but with a better internal design.
I think both versions are useful.

Not exactly. The first version of the editor was intended to be a fully fledged level editor like Valve Hammer or Unreal Ed. Unfortunately, this proved to be more work than I was able to achieve in my spare time so instead I cleaned up the code and released the Lite version.

I think it's always better to finish a project with less features rather than have a half finished project with lots of half finished features. However, I realise it doesn't provide as much value as it could which is probably why there isn't a lot of interest in the Lite version. I'd still like to finish a more complete editor but right now this is it.

I never really re-wrote the whole editor, nor did I remove any features except those that didn't work. Developing software can be a messy business sometimes. Reworking the design is a constant process, rest assured though, I only ever changed the design so that I could add more features.

I'm not very proud of the history of this project. It's been far more icky than I would have liked. At least I've learned a lot though
What would you like to happen with this project?

In the wiki page I updated the See also section now.
I added a link to this new forum topic.
Also I restructured the old links for a better overview.

As always, thanks for your significant effort Beauty You're a very valuable member of the Mogre community.

Hey zarfius,
thanks for the code! I already took a look at it and it seems to be very useful to me. I will probably use the editor (with some modifications to fit my engine) for my game. Thanks to OOP it is all compatible

As a feedback:

1. it compiles and runs out of the box without problems[/*:m]
   
2. the code looks clear and well commented[/*:m]
   
3. the storing via a database is pretty cool[/*:m]
   
4. it seems to me like being programmed in an elegant way (regarding GC and stuff)[/*:m][/list:u]
   Besides of that it appears to me that the concept of my engine is not so unusual (one static engine class with manager classes dealing with different aspects).
   
   Thanks again, this is a great contribution to the community and nice for beginners to take a look at!

thanks for the code! I already took a look at it and it seems to be very useful to me. I will probably use the editor (with some modifications to fit my engine) for my game.

No problem. I'm always pleased to know when someone is getting use out of it because sometimes I've done all this work for very little reward. If you have any problems with it I've always got an open ear and equally, if you make any major improvements I'd love to know so they can go back into the main source for everyone else to benefit

the storing via a database is pretty cool

I was never really happy with the way I did the storage side of things. I had a go at putting it into a database and also saving things to XML files using a project structure similar to Visual Studio. Both methods have pro's and con's but from memory I think the XML files was the end result (there may be database stuff still around but I'm not sure if it's fully funcitonal). I think it works okay they way it is, but sometime I'd like to get back to it and approach it from a bit of a different angle.

Besides of that it appears to me that the concept of my engine is not so unusual (one static engine class with manager classes dealing with different aspects).

Yes, the static engine class (singleton pattern) certainly makes it easy to access the lower level systems from anywhere within the code. Although, it does tend to lead towards tight coupling and hidden dependencies. There are plenty of articles on the net explaining why this is bad.

In my recent work I've been refactored the engine class to not be static and use constructor injection instead. This solves many of the problems with singletons but requires a fair amount more thought to get it right. Most of the concepts are the same though, the engine class still contains manager classes for the sub-systems.

Thanks for the feedback

back into the main source for everyone else to benefit
I will try but most likely it will be deeply connected with the engine that is really focussed on the kind of game I am creating right now. Anyways if there are some improvements I will let you know!putting it into a database and also saving things to XML files
I know the pros and cons. I also thought a lot about it. I have actually no idea what is faster and better for memory in the end. XML files can be pretty easy especially when you are using .NET's serialization. On the other hand you do not have to deal with several files when you choose a database... pros and cons on both sides

Concerning static classes: I also had static classes at first but know decided to have it non-static and to save a reference in every manager class so every object can get the engine via the manager it is attached to.
Personally I prefer non-static classes because you really have the power to decide when they are created and destroyed...

You are welcome, I will let you know about problems, difficulties and other things I experince while working with it.