System - issues like threads, storage etc.

Crash on quit

Done? Problem is at least much diminished, if 1) I create windows from only the main thread, and 2) don't exit before the non-main threads have finished. This is probably a fact of life that is just much more poignant in Python. It can be kind of difficult to achieve #2.

C storage vs. Python

What a mess. Most functions take their data pointer, do what they need and let it go. Some, however, take the pointer and squirrel it away, in which case it needs an incref to pin the Python version up. This appears to be a case-by-case research project. Other functions may later release the pointer, and we'd like to decref at that point, but I can't bear to even think about that. Maybe just RemoveChild() and the like, but basically anything that overwrites or clears a pointer we made a reference for. The "incref" option is duly noted for a few functions, probably not all that need it. A similar option "dup" is for cases where it seemed better for one reason or another to make a copy.

Reference counts for wrap instances

Need more research, but I have reason to suspect that there are some extra references somewhere that keep the instance from ever getting to refcount 0 once it has been bound - despite attempts to unbind with bind(None). Pretty sure some of them are actually references to member functions. I will fix this stuff if I figure out how -- and the result may be inconvenient for you, if you have been depending on this bug that allows your BWindow objects to persist despite no apparent references!

Inheritance details

I know empirically that BColorControl::SetEnabled is different from BControl::SetEnabled so I can't just inherit the function from BControlmodule.so. I know from explicit BeBook documentation that other functions are like that. Wish I could get it from the .h file. Don't want to duplicate all functions, unnecessarily.

be_bold_font depends on BApplication()

If I import BFont before then, I lose. (Is that still true?) Very awkward. Need to fix up be_bold_font later, on demand? Check that preset handling actually works for multiple presets per module.

Interpreter lock over-use

Think about eliminating the thread unlock/lock around some of the function calls. Most of them are fast and therefore don't need to release the interpreter lock. Don't have any idea how much advantage this would be. Since I am not hurting for performance, the incentive is not strong.

After BBox::SetLabel(BView*), python has a problem on quit that's typically due to bad refcounts or other memory mis-de-allocation. (This problem disappeared in Python 2.1, don't know why but I'm not complaining.)

Python interface

Doc strings

Add doc strings. Maybe combine with function call parameters exception string. Given what I already have to work with, the doc could show the return object type(s) as well as the params, which would be good, but I think it would be more useful with parameter names per the Be Book. Which I don't have.

Compiler

Function stanza order errors

Warn or something when missing return/status etc. in first fn of multiple input overload, where return/status etc. was probably intended to apply to all.

Parsing

More tolerant whitespace handling.

Unsupported types

Array of char*, many of these in omitted BFont functions. I think that can be addressed with new type, in sgrules, in general zero terminated vs. dimensioned.

BList, pattern, various other compound types.

Virtual functions with write parameters

Need some notation, I guess, haven't really looked at it. E.g., GetContentLocation(float*,float*)

Horrible coding mess

Rewrite everything, maybe ditch m4.