Recursive execution of main loop from within event handlers.

[GoogleCodeExporter]

This is a feature/enhancement request coming from the FIFE usage
of guichan.

First of there are a lot of possible issues if within an event handler
the widget is manipulated. Take Gui::distributeMouseEvent.

If inside one of the listeners the widget gets deleted there are no further
checks for the widgets existence. Then if a listener gets deleted this may
also result in a crash.

Somehow this doesn't really happen - we use a python wrapped guichan which
garbage collects widgets only outside event handlers - and even then this
could be worked around.

But we try to offer synchronous dialogs. This results in a recursive call
to our main loop from within an event handler. Now when this happens, the
Gui::logic function is frequently only half-way done with its work.

Here's a proposal how this problem could be solved.

I would like a more fine-grained control over event distribution. So in
addition to the logic function a processEvent function, which processes
exactly one event from the input deques and a flush (or somthing like that)
function, which can be used to clear the processEvent functions internal
state and can be used when the call-stack finally returns from
the recursive call of the main loop.

Maybe I am missing another solution and I think we are pushing the limits
of dynamic usage here.

Happy hacking :-)

Original issue reported on code.google.com by klaus.bl...@web.de on 16 Oct 2008 at 6:12

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Your proposal is interesting and I don't really see a harm in adding it as it 
won't
break anything. Of course, the usage of a flush function might be a bit tricky 
as it
would prevent an event from being further distributed to listeners who haven't 
had
the chance the process the event.

When events are consumed in Guichan they are still distributed to listeners but 
with
the difference of being marked as consumed. The reason for this is that Guichan 
only
has one type of focus and that is a combination of input focus and activation 
focus.
A container for instance isn't focusable because we don't want a container to 
get
focus when a user uses the tab button to cycle through all focusable widgets. If
someone wants to implement a menu widget that shows itself if a container is 
right
clicked, consumed events become important as the menu should hide itself if 
something
outside of the menu is pressed. In Guichan this is done by listening for all 
input
from a container, non consumed and consumed, and hide the menu if the input 
didn't
concern the menu. 

If Guichan would have two types of focus a menu would only be interested in non
consumed event and hide itself whenever it loses input focus. With two types of
focus there would be no need to distribute consumed events, so marking an event 
as
consumed would basically have the same effect as flushing the event processing.

Perhaps we should think about adding two types of focus two Guichan as well?

Original comment by olof.nae...@gmail.com on 16 Oct 2008 at 4:37

[GoogleCodeExporter]

For now please close this issue.

I will batch the events and later (after Gui::logic) process them in order.
That has its own issues, but should work way better than enforcing some kind
of state in the event processing in guichan.

-phoku

Original comment by klaus.bl...@web.de on 21 Oct 2008 at 7:23

[GoogleCodeExporter]

Original comment by olof.nae...@gmail.com on 21 Oct 2008 at 12:01

• Changed state: WontFix