Re: [Adonthell-devel] User interface open items

[Kai Sterker]

On Fri, Jan 27, 2012 at 7:10 PM, StyxD <address@hidden> wrote:

> Basically, there'll be a python module that has a persisting event
> factory that creates events for closing and moving text balloons.
> It'll keep a list of currently displayed balloons too, just to avoid
> messing with "thisown" once and for all. I originally intended
> comments to be created as objects and then handling all the
> displaying/event stuff inside, but it seems to be problematic.
>
> Is that an OK design (persisting objects in a module, I mean)?

Should be okay, as part of the actual game implementation will be on
Python side anyway. (Items are mostly Python modules, for example, so
they are persisted from a module as well)


> By the way, is there some way of passing arbitrary arguments to a
> python function called from an event? There seems to be one method for
> that, connect_callback from listener, but it requires full path to the
> function in a file (I suppose it's used for all those map events) and
> it seems impossible in event factory (where the python version of
> register_event just converts the call to a c++ functor.).

You can only do it through the low level interface, as you already
figured out. There's an example in test/eventtest.py

    lst = fty.add (ev1)
    lst.connect_callback ("time_events", "event_script", "callback_1",
("#1", 1))

In there we pass the string '#1' and the integer '1' as additional
argument. The callback in
test/data/game_events/time_events.py then has the following signature:

    def callback_1 (self, lst, evt, str, num):

The last two arguments are where it receives the string and number.
The only restriction here is that those additional arguments must be
persistable themselves. This basically limits them to strings and
integers. See python::put_tuple(...) for the reason.


The alternative (although not sure if that is viable in your case)
would be to pass additional data through the event structure itself.
The triggering event is always passed to the callback (the evt
parameter in the example above) and can be used to convey runtime data
that needs no persisting.


> I don't strictly need this, but it just seems weird to me.

I think I added the python version of factory::register_event as a
shortcut, for when you don't need the persistence. But initially you
were supposed to make the two steps by calling factory::add and then
connect the callback to the resulting listener by specifying the
module, class and function name. That way, the callback can be
reconnected when restoring a persisted factory. (I guess all that data
could be gathered via introspection nowadays, but I'm not sure if that
was already possible with Python 2.0 back then.)

Hope that helps explain the weirdness. If you can think of better ways
to handle this, we can improve the API at that point. Most of the
stuff has been written a long time ago and could have been designed
better.


> I hope I'll be able to get this done by the end of the next week.
> Sorry for the delays.

No need to apologize! Looking forward to the resutls, however :-).

Kai