CEGui+ogre
Posted: Fri Jul 16, 2004 06:38
Okay, thanks for the questions 
I'll answer the points out of orders since the questions are related, and earlier answers basically answer later questions.
There is no VC++ 6 project/workspace files at the moment as compatibility work is needed. This will be happening shortly, but I have no ETA for it.
All raw inputs are injected into the Gui system by the client application. In the demos, these inputs come via Ogre. This has two main implications; first, is that it's up to the client application where the inputs come from (i.e. you are not obliged to use the Ogre input system), and second, the client does not have to feed all inputs into the Gui system...
There are various ways to solve your focus switching example. The solution you gave is certainly valid. But the point above about the client not having to send all inputs into the Gui is valid here - basically, you could set your application up to detect the Tab key independant of the Gui, and hold a state variable that determines whether raw mouse input is consumed by the application (for mouse look), or whether raw mouse input is sent to the Gui system.
For event propogation, you are mostly right, the full story is as follows (and has a small potential issue, as i'll mention).
Raw input (mouse movement, mouse buttons, keys, and characters) are taken from whichever input source is being used (in the demos this is Ogre), and are injected into the Gui 'System' object. The system object looks at the input, possibly does some translation and/or conversion with it (the Gui system will generate certain events, like double-clicks, from the raw inputs). The 'event' is then passed to the active window (which is usually the top level window/widget but may not be) - when I say passed, this is done via a direct method call on the target Window of an appropraite 'on<some event>' handler. The handler may or may not handle the input, if it does not handle the input, the input is sent to that Windows parent until it is either handled or until the last Window rejects the input. Now, this only happens for input events, other intenal events (like 'window sized' or whatever) do not propogate back up the chain. The 'on<some event>' handler will also fire/raise an external signal - this is the subscription system and gives client code full access to all events on all windows. The potential issue I mentioned is that when you subscribe your application to the input type events (that is, the ones that travel back up the parental chain), you can't signal that you have handled the event in client code, so this means that the event will still be sent to the parent (until a Window handles it internally) - this behaviour may or may not cause problems for certain people in certain scenarios. The internals of this system may change in the future, though the interface for client code will remain stable.
HTH
CE.
I'll answer the points out of orders since the questions are related, and earlier answers basically answer later questions.
There is no VC++ 6 project/workspace files at the moment as compatibility work is needed. This will be happening shortly, but I have no ETA for it.
All raw inputs are injected into the Gui system by the client application. In the demos, these inputs come via Ogre. This has two main implications; first, is that it's up to the client application where the inputs come from (i.e. you are not obliged to use the Ogre input system), and second, the client does not have to feed all inputs into the Gui system...
There are various ways to solve your focus switching example. The solution you gave is certainly valid. But the point above about the client not having to send all inputs into the Gui is valid here - basically, you could set your application up to detect the Tab key independant of the Gui, and hold a state variable that determines whether raw mouse input is consumed by the application (for mouse look), or whether raw mouse input is sent to the Gui system.
For event propogation, you are mostly right, the full story is as follows (and has a small potential issue, as i'll mention).
Raw input (mouse movement, mouse buttons, keys, and characters) are taken from whichever input source is being used (in the demos this is Ogre), and are injected into the Gui 'System' object. The system object looks at the input, possibly does some translation and/or conversion with it (the Gui system will generate certain events, like double-clicks, from the raw inputs). The 'event' is then passed to the active window (which is usually the top level window/widget but may not be) - when I say passed, this is done via a direct method call on the target Window of an appropraite 'on<some event>' handler. The handler may or may not handle the input, if it does not handle the input, the input is sent to that Windows parent until it is either handled or until the last Window rejects the input. Now, this only happens for input events, other intenal events (like 'window sized' or whatever) do not propogate back up the chain. The 'on<some event>' handler will also fire/raise an external signal - this is the subscription system and gives client code full access to all events on all windows. The potential issue I mentioned is that when you subscribe your application to the input type events (that is, the ones that travel back up the parental chain), you can't signal that you have handled the event in client code, so this means that the event will still be sent to the parent (until a Window handles it internally) - this behaviour may or may not cause problems for certain people in certain scenarios. The internals of this system may change in the future, though the interface for client code will remain stable.
HTH
CE.
. If I make good progress today, I may install it tomorrow 
I don't know if Ogre will compile with VC++ 2005, some people on the forums over there have tried and not had much luck - though you seem to be doing well with everything else, so maybe you'll do okay with that too 
