I recommend you read this blog post (it's part of a series which is itself pretty interesting) talking about one developer's experience with trying to use Qt for his main game UI, and the performance problems that it caused him. Qt is pretty heavy-weight. It's useful as hell, but that usefulness comes at a pretty significant performance cost. It really isn't designed for game UI. Game UI tends to be more highly specialized, since it needs but a fraction of the features something like Qt provides, and as a result tends to be more highly performant. CEGUI was built more with games in mind than Qt, but it also offers a measure of flexibility (and the attendant complexity).

The game engine is a pile of linked code, it doesn't need a UI.... or are you thinking about making a level editor? If you're wanting to make a visual tool to help make your game then yeah, you could use Qt for that... but that's a whole other level of complexity that I wouldn't recommend. Unity, UDK etc. have their own world building tools, because they sell them... making your very own level designer is a project by itself.

Every part of my engine (except the source code) definitely needs a UI because if it doesn't, there is no way i'm going to be motivated to make anything in it. The UI i am refering to is what you see when you load the engine like the menus you see in torque 3d. UI's are really (really) important to me.

I never worked with Torque, but from what I could see, it seems you are referring to the GUI of the editor. While this might be accompanied with the engine, it's not the underlying actual engine that does all the rendering/audio/etc.

It's usually your engine at work in the editor so you will be able to achieve "what you see is what you get" when comparing what you see in the editor to the game. With that being said, what Godmil actually said is perfectly valid: Anything beyond the basics (even some of the basics) is a project in itself. Doable, sure, but I would advice to at least get to know Ogre3D first, how it works and such before making an editor for it. Perhaps even better, I bet there's already plenty of level editors to some degree out there for it.

Judging on your (past) posts, I strongly suggest you read Game Engine Architecture by Jason Gregory to get familiar with how things actually work (it uses Ogre as a referrence as well), because at the moment it seems you are mixing things up and/or misinterpreting how stuff actually works.

Every part of my engine (except the source code) definitely needs a UI because if it doesn't, there is no way i'm going to be motivated to make anything in it. The UI i am refering to is what you see when you load the engine like the menus you see in torque 3d. UI's are really (really) important to me.

I never worked with Torque, but from what I could see, it seems you are referring to the GUI of the editor. While this might be accompanied with the engine, it's not the underlying actual engine that does all the rendering/audio/etc.

It's usually your engine at work in the editor so you will be able to achieve "what you see is what you get" when comparing what you see in the editor to the game. With that being said, what Godmil actually said is perfectly valid: Anything beyond the basics (even some of the basics) is a project in itself. Doable, sure, but I would advice to at least get to know Ogre3D first, how it works and such before making an editor for it. Perhaps even better, I bet there's already plenty of level editors to some degree out there for it.

Judging on your (past) posts, I strongly suggest you read Game Engine Architecture by Jason Gregory to get familiar with how things actually work (it uses Ogre as a referrence as well), because at the moment it seems you are mixing things up and/or misinterpreting how stuff actually works.

See it like this:

For your game, you want something function, but doesn't slows your game down to a slug. CEGUI is (appearantly, I never worked with it directly) one of the better options for that.

For your editor, you probably still don't really want it to slow down by a lot, but it's a stand alone application that makes use of your engine (doesn't even need to), The stuff your UI needs to do in here is probably a lot more varying than what it should be able to do in your game, or more data oriented I guess. So QT might be the better choice here, provided it does what you need for the editor.

So it's just weighing off your choices. What do you need, do you need full speed for the editor etc.

I didn't do any proper GUI work to give you the final solution, but if I would, those are a few of the questions I would ask myself when making something.