Announcement of another python-gtk - co-author searched !

[Joost <joost h-labahn de>]

Hello,

these days i published depikt on sourceforge.
depikt is a bundle of python wrappers for
gtk in one file, used by me as a replacement
for pygtk.

depikt has quite another strategy than pygtk -
nobody will ever be able to create widgets
with it. Depikt will probably translate nothing
from GLib for Python (and never ever GValue or
GParam) and thus never support set_property().
Depikt just calls gtk.init(NULL, NULL)
when imported from a python program first, then
creates Widget pointers on request and calls their
methods - not even complete in that respect too.

It is only there to build GUIs for applications
and - at least at this stage - not even gnome
applications (no atk). A version supporting a
current midsize python project of me can probably
stay below 2.000 lines, certainly below 3.000. This
.pyd shared lib will have less than 100kB. Thus the
code is very easy to be read, maintained and amended
by anyone without fear of C and the technique of
Python extensions.

But - being an experienced Python programmer, C
and the large GTK+ object system is still a challenge
for me. And it's not my first Python extension made
with C, but the first more ambitious.

Depikt realizes the abstract base classes like Widget
as abstract python classes having no __new__-constructor.
That is no standard concept. Currently there appear
mysterious errors with heirs of depikt classes in the
second generation. Perhaps i have to call Py_INCREF(...)
more often than i do now, but i do not think so. depikt
depends on the fact, that a GtkContainer* is a GtkWidget*
for example - perhaps it's here where things go wrong.

Currently depikt has the MIT-license. Because of its
simplicity i hope for users, who make own versions of
it - thus i'd prefer public domain in the long run.

Now i search for someone, who really does like the
concept, proofreads the code and helps me to find
the mistakes. You can email me via sourceforge -
i'll send code examples raising the above-mentioned
mysterious errors to any interested gtk-programmer.

depikt will prevail anyway - in the worst case these
errors can be still worked around apparently.

Thanks for reading, Joost Behrends