Hello,

these days i make depikt, a new minimalistic gtk-interface, published on sourceforge.net. For Python3, what all here is referring to.

First there were abstract classes for Container and so on - they have been replaced by method bundles added by the preprocessor to the individual derived widgets, which of course are extension classes.

Using one baseclass for gobjects, called Pikt.

I knew, this would not be simple, but what i hadn't any idea of are the problems Python causes here. From cStringIO i knew, that there were some not subclassable Python types, but i took that for an exotic exception. I also had no idea, that dynamic attributes are no standard behavior (having never tried [1,2,3].a = "new attribute" at a python prompt).

I've got dynamic attributes now, and inheritance from the lower level classes in pango and gdk. But inheritance for gtk.Window or gtk.VBox is much more important in practice and after about 3 days of trying (with TPFLAGS_HEAPTYPE for example) and reading in object.c, objectimpl.c or typeobject.c depikt's widget classes are still "idempotent":

class myEntry(depikt.Entry): ...

doesn't crash but its __init__ creates - perfectly usable - objects of the type depikt.Entry (what can be iterated). A funny behavior, but seen from a strict perspective a bug in the C-API (should crash. Or are all such classes "idempotent" and is this needed internally ?)

This here is from the preprocessor factory for the widget types (initialized for Button for readability) and from here the problem might stem:

378 PyObject *Button_new(PyTypeObject *type, PyObject *args, PyObject *kwds) {
379 Button *self;
380 self = (Button *)Pikt_new(&Button_Type, args, kwds);
381 self->Q.gobj = PyCapsule_New(newfunc, "Button", NULL);
382 if (! self->Q.gobj) { Py_DECREF(self); KTERR("Cannot create Button");};
383 return (PyObject *)self;\

That means, from line 380 (which follows a recommendation of the tutorial and is vital. It also took nearly a day to find out, that Pikt_new can accept a Button_Type*, that is not documented and far from obvious).

Could somebody give me a complete list of obstacles for inheritance from the C-API ? Including the nexus to allocation ? I do not mean explicit explanation of each obstacle. Hints for each item are fully enough.

Thanks for reading, Joost