Python classes for BeOS C++ API, version 0.2.1.

At this point (April 2001) what we have here is Python classes for C++ programmers.

If you're a Python programmer and not a C++ programmer, and only want to use the modules, the worst problem is just documentation, or lack thereof. We have none, we rely entirely on the BeBook documentation of the C++ API. And there are some transforms between that and this Python API that should fairly obvious to someone who understands both, but maybe not if you only know Python.

There is hope, though, since at least there are some example programs. If anyone wants to contribute more example programs, incidentally, that would be great. There is also usually included with this distribution a real application, maybe not the slickest thing in the world but I use it.

Credits - I got some of the ideas in this system from a paper by Jim Ahlstrom, though they've probably been perverted beyond recognition and the resulting mess shouldn't reflect on him at this point.

Step one: Python

Get Python. I think at some point this could be a binary distribution, including Python, but at present you have to get Python separately. Starting with Bethon 0.2.1, I assume you have Python 2.0, but 1.5.2 will work too. No BeOS binaries are supplied for 2.0 at this point, so you will have to build your own.

I assume installation makes and uses /boot/home/config/lib/python2.0 and a subdirectory plat-beos5. (If you're using BeOS 4.5, it's plat-beos4; if you're using Python 1.5 on either platform, it's python1.5/plat-beos.) With Python 1.5 you'll need to do something about a missing dl_export.h in config.h, you can copy it from the config dir or just delete the include.

I use a file in the top directory "pythonversion" with one line PYTHONVERSION=2.1, and the makefiles can find that. You must however keep build versions consistent, don't try to run old modules with new interpeter or vice versa.

PPC and Intel are both supported, of course.

Step two: Build these modules.

Cd to base, run make.

Cd to build, run make. Then make install, to put the modules in the lib directory where python will look.

Cd to symbols, run make. Then make install, to install the symbol modules for symbols like B_QUIT_REQUESTED.

Step three: Figure out what went wrong.

If it doesn't work, I would like to hear about. There will be some errors in the compile, for sure - a few things I do the compiler doesn't like, plenty of functions that can't be compiled because we don't have type support for them yet.

The system.

Each module represents a BeOS API class. The source is a .dx file, using my own ad hoc notation. This is compiled with a Python program, "sg", to m4, a macro language that has been around for many years and happens to be supported on BeOS. m4 converts that to a .cpp C++ file, to be compiled and linked as a shared library.

There are 49 modules as I write this. Should be easy to write more - should be easier than it is! See Dx.html for more on this. Send along anything you can bear to see included here - we already have a few contributed modules. It doesn't even have to work right. Sometimes I can fix them. Sometimes there's a problem that I have to change the template compiler to fix, but if you wait for me to run into the problem on my own, it could be long wait! As I write this I'm sitting on some other contributed modules that need more thought than I have time for right now, that happens too.

The module for a derived class can fall back on its base classes - for example, the many BView descendants rely on the BView module for methods like Bounds(). They do this at run time. Virtual hook functions are also inherited, but not at run time - they're just pulled out of their respective .dx files at compile time.

Donn Cave, donn@oz.net