[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Adonthell-devel] Event system continued
From: |
ksterker |
Subject: |
[Adonthell-devel] Event system continued |
Date: |
Mon, 19 Apr 2004 10:17:14 +0200 |
Hi!
First of all some questions regarding map events:
Do we still have a grid? Or should map events be tied to a certain map object
or area? Or should I leave map events for now, until we actually have a map
again? ;-)
Now on to some good news:
I have completed and debugged the rest of the event stuff (haven't checked for
memleaks, though). I'll give some details below, but I'll also add a chapter to
the engine documentation.
The bad news are: I can't commit stuff at present as I still have net access at
the office only. (And since the iBook has neither floppy nor CD-R drives,
there's no easy way to get the code on my PC there) Sorry!
One thing I had to change in the underlying code was the Python instance
passing. The present implementation did not support inheritance, which caused
problems. When I pass a time_event, cast to event, SWIG would not know that it
is a time_event, and prevent casting the event back to time_event.
So I changed things to add the get_type_name () directly to each class, thus
recognizing a time_event, even when cast to event. The line in pass_instance is
now arg->get_type_name () instead of get_type_name<A>(). That also has the
advantage that the compiler complains if you try passing objects to python that
don't provide a get_type_name method. With the old code, it would compile fine,
but crash at runtime.
Other than that, the new event system has the following features:
* you can change the connected callback (or it's arguments) from within the
current callback. That means we can keep the callbacks small and limited to a
single task. If something else needs be performed, we can switch to a different
callback.
* as all events that use callbacks from the same Python class share actually
the same instance of that class, it should be possible for them to
'communicate' via member variables. (That occured to me just now, so I haven't
tested yet how well that will work). The problem with that is that the state of
such variables won't survive a reload.
* destroying the event from within it's callback is also safely possible. The
event managers take care of deletion after the callback returns.
One thing I wanted to look into is the following:
the steps to create an event on python side are:
# -- create the event
evt = event.time_event ("10m")
# -- aquire a pointer to a listener for that event
lst = event.factory.add (evt)
# -- register callback
lst.connect_callback ("file", "class", "method", (arg1, arg2, ...))
The problem is the second call. The event will be copied into the listener, and
the listener will free it at the end of its lifetime. However, since the event
is created on python side, it has it's thisown set to 1, which means that
python will also delete it. Crash! For now, one has to manually set evt.thisown
to 0, but a nicer solution would be to have that done automatically. This can
probably done with a SWIG typemap, or the %feature(shadow) thing.
I will have a closer look at this. But I think we should generally take care of
similar situations, to avoid errors because both C and Python think they are
responsible of freeing objects. That caused a lot of trouble while coding v0.3
python scripts, so we should do better in v0.4.
Okay, so much for now!
Cheers,
Kai
P.S: I'll look for a way to commit stuff, but it might take a while. I hope you
have patience ...
- [Adonthell-devel] Event system continued,
ksterker <=