Is there mechanism to find out if the event was used by the gui?

[GoogleCodeExporter]

When user clicks somewhere, I can't find out if the click was used by agui, so 
game logic doesn't have to process it.

Now I just process it by both gui and game logic, but it is often problematic, 
and we have to make custom workarounds, to not make the player do some action 
(shoot) when he is clicking button etc.

Original issue reported on code.google.com by kovarex on 24 May 2012 at 4:30

[GoogleCodeExporter]

The problem is, that at the moment when event is processed it is unkonwn how is 
it going to be used in the next logic step.

What if agui logic would generate list of events (not allegro events but agui) 
that hasn't been used by the logic?

Original comment by kovarex on 24 May 2012 at 4:32

[GoogleCodeExporter]

I used the:
gui->getWidgetUnderMouse() == gui->getTop()
condition, but I'm not sure if it is perfect.

Original comment by kovarex on 24 May 2012 at 4:50

[GoogleCodeExporter]

Hmmm... this is an interesting issue. None of the GUI in my game merges with 
the game so I never thought of that. What you posted will yield the result you 
want, but indeed it is a bit of a hack.

Should I create an interface for a callback for mouse and key events?

It's tricky because the event will always at the least be consumed by the top 
widget, but ignoring that, I could make a simple callback like:

virtual bool mouseEventConsumed(const MouseEvent& evt, Widget* widget, bool 
consumed);

Maybe even for key events too...

Currently Agui does support the opposite though... You can attach a global 
mouse listener and if your game consumes the event you can prevent Agui from 
using it.

Let me know what you think about the above suggestions and if you like one I'll 
try to whip something up.

Thanks

Original comment by joshua_l...@hotmail.com on 26 May 2012 at 10:03

[GoogleCodeExporter]

Well, I don't need that interface, the only problematic part is when both the 
game and gui need to use the same event, and it seems like this only appies for 
mokuseclick so far.

Our current logic is.
A)Process the event by game input handler (apart mouse clicks above agui widget)
  our game input handler directly returns if the event was used
B)If it wasn't used -> send it to agui

It is not really worth the work, but If I were desining the system with this 
issue in mind, I would probably inspect the need to separate gui logic call and 
event handling so strictly, logic would be still called, but event handling 
would "instantly" trigger the appropriate action, so the function could 
"instantly" return if the event was used or not.

I'm thinking this way, because using mouseEventConsumed, would force me to 
queue allegro events and filter them by result of the hook (mouseEventConsumed) 
translated back to allegro, (or calling logic after every event sent to agui 
and checking if the hook was called), this seems like not a good way to sort 
that.

Original comment by kovarex on 26 May 2012 at 10:21

[GoogleCodeExporter]

What if Gui::logic would return a bool indicating if it did something with the 
event? The tricky thing is that Agui is backend independent, and it supports 
polled input. In addition, in order to address a bug with tapping on laptops, 
agui stores mouse down events and waits 1 logic update to dispatch them.

The reason is that tapping results in a mouse down and mouse up but they might 
happen 1 frame in between so you would see 1 frame in the mouse down state 
which looked odd.

Original comment by joshua_l...@hotmail.com on 27 May 2012 at 12:56

[GoogleCodeExporter]

So the problem would be that the event agui just processed might not correlate 
with the latest allegro event which is problematic for your case.

Original comment by joshua_l...@hotmail.com on 27 May 2012 at 12:58

[GoogleCodeExporter]

I understand that the problem is, that allegro is just backend (and I really 
like that concept, that is why I chose this library in the first place).

I call Gui::logic only once per frame (is it correct?) but there might be more 
events during one frame.

What I wanted to say is, that the current method I described works perfectly 
for us, in other words, solving this kind of thing nicely might be nice think 
to do for some other cases, or for the sake of finding best design, but we have 
no practical reason to need it now.

Original comment by kovarex on 30 May 2012 at 12:37

[GoogleCodeExporter]

I suggest you call it once per logic update of your game (unless that is what 
you mean). Because if the game lags you want your logic to update and not a 
frame.

As or the issue, I have no personal need for anything more than the way you do 
it. It will always work (that's why I added getWidgetUnderMouse in the first 
place).

I'll leave the issue open anyways. If someone ever gives me a patch and I like 
it I'll apply it.

Original comment by joshua_l...@hotmail.com on 30 May 2012 at 2:18

• Changed state: Accepted

[GoogleCodeExporter]

Original comment by joshua_l...@hotmail.com on 30 May 2012 at 2:19

• Added labels: Priority-Low
• Removed labels: Priority-Medium