CEGUI Input Handling

[earthsruler]

On our project we have a system where input is giving to the the highest priority system. If that system reports that it has used the input then none of the other systems get it. This generally works well, as input will only be getting used by one system at a time so things like shortcuts wont be activated while typing in a text box.

There are some instances however where I have modified CEGUI to handle input a little differently which i will explain here for the CEGUI teams consideration.

Let me start with an example.

- You have a camera that moves when the mouse is moved.

When you mouse over some CEGUI items like a button it will stop moving as the GUI has reported it has handled the input, however other items like static text will return that they have not handled it resulting in the camera moving inconsistently as the mouse moves linearly over the GUI.

My solution to this, which i think maintains flexibility, rests in modifying the EventArgs object. I added a mutable bool called inputHandled. The idea behind this is that "handled" will signal that CEGUI has use the input internally, but inputHandled will determine whether it reports that it has been handled when the inject function returns. This way things like a button changing because of a mouse over wont report that it has handled input, however if someone wants it to they can subscribe to an event for that button and change the mutable bool inputHandled to true in the callback. This also works fine with lua callbacks and setting it to true there.

We have made things that definitely use input, like typing in a editbox and scrolling a list, always set the inputHandled to true, however more ambiguous things like mouse overs that could go either way return not handled and leave it to the users to modify it with a callback if required.

We also added a guard in the mouse up and key up events to prevent them doing anything if there hasn't been a corresponding button down first. That way CEGUI wont accidentally handle another systems input.

One last thing that we added that im not sure would be good for everyone was that any mouse clicks or scrolls over a CEGUI window that wasn't the root window reported that it was handled regardless. That way no clicks will go "through" a window and affect the world.

With this solution we have solved quite a number of behavioral issues we were having with CEGUI.

Sorry for the lengthy post but what do you guys think?

ER.

[CrazyEddie]

Hi,

Thanks very much for the post about this issue, and your perspective on the various ins-and-outs of it - it's very helpful to me. Why is this very helpful to me? Because this particular issue is a recurrent pain in CE's rear!

While nothing is going to get changed for the next 0.6.1 maintenance release, I do intend to modify the way inputs get marked as handled internally and the way that injected mouse and key events are passed back up the window hierarchy - perhaps substantially, depending upon what I come up with.

I've not decided on a final approach to take yet, just that something will be done; this is why your post is so useful to me, since it gives a perspective of the system in use, and what you were maybe expecting from the system, and the contrast between that and what you actually get at the moment.

What I might actually do is, in a few weeks, post here with my intended solution to try and get some feedback on that before implementing anything. So, thanks again for posting what you've done to solve the issue for yourself and why

CE.

[earthsruler]

Glad it was useful! Our solution was a "patch" to get the behavior we wanted fast. A much more elegant solution would be to have it specified in data. That way you could specify the way particular window objects report they handle various forms of input externally. Not only is it less expensive (as it saves callbacks) but you can easily change it to suit your applications needs. It also doesn't bind CEGUI to one persons view on how input should be handled , and could be changed at run time!

I look forward to hearing what you come up with.

ER.