Re: [Adonthell-devel] Python tests not working anymore

[Kai Sterker]

Am Dienstag, 03.02.04 um 23:01 Uhr schrieb Alexandre Courbot:

> > As an aside: running those python scripts from a seperate build dir
> > works fine on OS X. I don't really know what is going on.
>
> I don't neither. I've turned the main module into something completely 
> static,
> and, guess what, it works now. I haven't done everything however, it 
> still
> needs some more work before everything works as before. Maybe it 
> didn't like
> the fact that ld_handlers were not static, or something like this.

Hm. I believe I had them static first (or at least allocated on the 
stack) but ran into problems with that :-). But if it works for you, it 
should be okay.

> Anyway. I was wondering about the usefulness of the main module. How 
> about
> moving it's semantics to base? Or maybe it should even go directly to 
> src/
> without belonging to any module. The app class will be very light 
> after my
> changes (actually, not much more than a virtual method called "main", 
> as you
> can guess), so since it's just an interface and a main method, it 
> sounds ok
> to me to put them in src/, along with an "adonthell.h" file that every
> application would include.

I thought about this myself. It might go into base, I guess, but not 
directly into src/:

* First, we'll have several backends for main, as different 
initialization will
  be needed for different gfx libraries.
* Second, I thought we might add some more functionality later on, like 
setting
  the backend to use in the main module, so that all the other modules 
can get
  it from there. (instead of passing it directly to each module as we 
do now,
  assuming that we do not want to mix different backends.
* Finally, I was thinking about a graphical game launcher that would 
appear when
  starting adonthell (similar to ScummVM), so that people can start any
  installed game without the need to use the command line. I guess that 
would
  also go into the main module.


> About Python, I was wondering whether it would be possible to keep the 
> same
> structure for applications (i.e. a class named theApp). I'll look at 
> that
> once the main stuff is fixed.

SWIG 1.3.19 offers something called director classes. It allows to 
subclass C++ classes on Python side in such a way that C++ knows about 
them. I tried using it to achieve what you suggest, but again had to 
give up on it. The problem is that this feature makes use of C++ 
exceptions, which we have turned off. But turning them on did result in 
errors in other modules.

But maybe there's another way.

Kai