Concerning the behavior of getNextTargetWindow

[Thaedrys]

Please correct me if I am misunderstanding anything, but shouldn't getNextTargetWindow be doing a full post-order traversal? It appears to be drilling down to a leaf of a hierarchy but when it collapses it never checks the siblings of any of the visited nodes.

Read on for a more detailed explanation of my question.

Say I have a couple windows with a parent hierarchy like so:
[font=Courier]
<pre>
A
--------
| |
B(top) C
------ -------
| | | |
C D E F(listener)
</pre>
[/font]
All of the windows are occupying the same 2d space (overlapping), Window B is set to be always on top. Window F is the only window which has a mouse click listener set up on it.

Now assume that a mouse click is registered by the system using injectMouseDown. The current implementation of getTargetWindow would start at A, drill down to B, then down to C, returning C as the targetWindow.

C doesn't accept mouse clicks though, so getNextTargetWindow is called. All that getNextTargetWindow does is move up to the parent. So we check B, which refuses the event. Now we're back up to A which also refuses the event, and the event is reported as being unhandled.

There were 4 windows that were not checked, including the one window that does handle mouse clicks.

So, shouldn't the whole event path be modified to perform a post-order traversal to make sure none of the windows are missed?

-Thaedrys

[lindquist]

Imagine having two framewindows.
one is empty and one has a big button in the centre.
set the areas for both framewindow to be exactly the same.
now if the empty window is on top and you click the background in the centre, the button on the invisible framewindow will receive the mouse event.

Is this really the behaviour you want?

I do agree that the current implementation is limiting in some cases.

perhaps a new setting which controls if a window should be treated equally to its siblings regarding the event (if the first-reveiving siblings do not consume the event) ???

I'm assuming that you want this to occur with defaultwindows (or other transparent windows), right? so only the default windows would need this setting flagged.

[Thaedrys]

Yes, I agree that the example you stated is a behavior you would not want. And yes, you're right on the money that I think this should be a "flag" that could be applied to default windows (or any window that you want events to pass through).

I'm not sure if you noticed my post in the Help forum, but that post is related to this issue. If multiple default windows are on top of one-another (in an effort to layer multiple GUI layouts) they block any input from going through them to other controls that want to do something with them.

I think that if a window does not want to handle the mouse event, it should either be allowed to consume it anyway (to prevent windows underneath it from getting the event) - which is the close to the current behavior, or it should be allowed to let the event pass through to any windows underneath it - which would require a more involved event propagation method to be written which takes siblings into account. I have seen this idea of a pass-through control in a couple of the other game GUI systems I've worked with and I think it makes sense that if a window can be transparent visually, it should be allowed to be "transparent" to mouse events as well.

What do you think?

BTW, please let me know if I can help out with this on the development side. I'm using CEGUI for a personal project right now and would love to help further its development. It's a nice GUI library.

-Thaedrys

[Thaedrys]

I came up with a solution for my problem which does not seem to have any adverse effects (at least none that are immediately apparent) and just thought I would share in case anyone wanted to implement something similar. I was actually able to make the change without touching getNextTargetWindow.

I added a new property to the Window base class called d_allowMousePassThrough. This is set to false by default. The GUISheet child overrides the property to be set to true.

Then, in Window::getChildAtPosition I changed the following line:
<pre>
[font=Courier]
// see if this child is hit and return it's pointer if it is
else if ((*child)->isHit(position))
return (*child);
[/font]
</pre>
to:
<pre>
[font=Courier]
// see if this child is accepting mouse input and is hit and return it's pointer if it is
else if (!(*child)->getAllowMousePassThrough()
&& (*child)->isHit(position))
return (*child);
[/font]
</pre>
This effectively allows all mouse input to pass through GUISheets to any controls beneath. By adding this flag as a mutable property, it is also possible to create an entire set of Windows (of any subclass) to be "transparent" overlays that allow mouse input to pass through them.

-Thaedrys

[lindquist]

I think your approach is nice, and I have committed it to the v0-4 branch with a few small changes.

First I did'nt want to break the behaviour of getChildAtPosition, so the a new method getTargetChildAtPosition has been added.

The Property is called MousePassThroughEnabled, and the getter/setter : isMousePassThroughEnabled, setMousePassThroughEnabled

System now calls getTargetChildAtPosition to find the window to receive the mouse events.

I committed most of it last night, but I forgot CEGUISystem.cpp, so it will be around 24hrs before it reaches anonymous cvs.

Remember to update to the "v0-4" branch, as CVS HEAD is something completely different (and I had some weird merge conflicts, but I'll get it in there as well tonight probably)

Thanx for showing the way to add this cool feature

[Thaedrys]

I was a bit worried about the potential breaking that could occur by changing getChildAtPosition - making it a new function is a good idea . Overall, I'm glad this change made it into the branch - I'll update to the changes in a couple days.

Glad I could help .