:oops: sorry if it came to sound like a "flame" of the event managing way you have choosen to use.
That's cool. No need to apologise - you can say whatever you want
I just think that when using CEGUI in a target application compared to how ogre works, the eventhandling looks and feels better in ogre.
Prior to writing the GUI Renderer class for Ogre, I had never used Ogre (though I was aware of the project). I do not have any experience using Ogre in an application, so can't compare the two or comment any further on that side of things.
I didnt mean how it was ment to do on the inside of CEGUI, do you have some design notes about your eventsystem ? maybe some UML diagrams or something, It would be great for me to get a larger view on how things work.
I can't design at a computer. All my design stuff is done as scribblings on paper, I did have a diagram of all the classes in the system and how they interact with each other (not much on the input system though), I can't find that stuff at the moment - I may even have binned it all
(it will probably turn up eventually, I hope so because I wanted to use it as the basis for some of the docs
).
I'll just waffle on for a bit about the internals of the event system instead
...
The system for inputs entering the GUI is basically the same as it was in the older versions (though simplified, the System object can now auto-generate some events itself based on the events it is given - like double clicks are generated from mouse down events). The GUI does no discovery of inputs on its own - all inputs are fed into it. These input events are then forwarded to whichever window (every UI element is a window) has focus (or has captured input) - via an on<some event> handler (such as onMouseMove). Each specialisation of the Window class overrides the on<some event> handlers for the events/inputs it is interested in (and may define other on<some event> handlers which may be further specialised in derived classes. For the input events, any input not handled (signalled by not setting the 'handled' field in the passed EventArgs object to true) is passed back up through the parent window(s) until it is handled or the top of the window heirarchy is reached. An on<some event> handler may also fire an external event which can be subscribed to by interested parties (though presently no 'Input' event ever fires an external event).
The external events and subscription system was partially inspired by the way that .Net and C# handles events, and obviously uses boost::signals internaly to implement the system. The base window class has a large number of external events available (at this stage some are still not wired up yet), and other windows and widgets define new external events as appropriate. Every external event is matched by an on<some event> handler in the class that defines the event, though (as stated above) not every on<some event> handler will have a corresponding external event.
Im going to wrap up a small "OgreRefApp::GuiManager" framework which is able to utilize CEGUI as a guisystem. or any other system out there for that sake, that was what i had in mind when I wrote the last post, i just wanted to hear your oppinion
I see - why didn't you say so
I'd be happy to see what kind of thing you come up with. Don't think that when I say I'm happy with things how they are that I'm not interested to see how others are able to change / use / integrate the system. Or that I'm not open to feedback and suggestions - the system is how it is now
because of feedback and suggestions
I wondered when this would come up 
. I'm going to have to add a setting of some kind to the Ogre GUI Renderer where you can specify which scene manager you want to use, as at the moment it's hard coded to ST_GENERIC. It's on the long list of things to do...
