depikt (gtk-wrappers): Threads, inlining Pixbufs to python code

DreiJane joost at
Mon Nov 23 15:33:27 CET 2009


these days i make depikt, my replacement of pygtk. There are several
reasons to do this:

- Support for Python3

- Exact control of encoding issues. I myself (a German) hope to
abandon with any python unicode objects forever in future - that is,
why Python3 is an important improvement for me. I'll also make a
version of apsw leaving alone the utf-8 sqlite works with. And in
the long run perhaps one of the python-API of the monet database. A
preprocessor macro DEPIKT_USES_BYTES decides, whether depikt
communicates with python via bytes or (unicode) strings - the actual
setting in is, that DEPIKT_USES_BYTES is defined.

- Readability and changability of code. pygtk's hundreds of files are
too much for me - since i will make own widgets with C, not python,
the work of understanding this would be wasted for me. All the more,
as pygtk's sources are templates for an own templating
system, not .c-files - can this really be called "open source" ?

- "Ambulancy". All other tools i use can be installed by simple
copying (or compiling via distutils without autoconf) without admin
rights: eclipse with pydev, mingw, gcc4.4, apsw, cython, gtk are
"ambulant". Only setting the environment variable PATH in a local
environment is needed for gtk. Not so pygtk: It searches for python in
the windows registry or has to be compiled with autoconf. There are
not neglectable traces of trouble with installing pygtk on the web.

A drawback: To install depikt you must compile it. But by python's
distutils, which make compiling absolutely easy. Still you have to
edit the provided, i will not automatize the use of the
output of pkg-config  for gtk. But that really doesn't need much C-
knowledge (a bit knowledge of how C-compilers work is essential

depikt comes with new features: depikt.gdk_threads_enter (and leave)
is supported. Again controlled by a preprocessor macro
(what is the default), each gtk.main() has to be prepended by
depikt.gdk_threads_enter() and - with more than one - must be followed
by gdk_threads_leave(). Admittedly gtk threads aren't really
intensively tested now (but gdk_threads_enter is only protecting
values in the thread's namespace and is safely ignored, when gtk is
initialized without support for threads). Since you must arrange anyway to use depikt, these macros are no obstacle.
Nevertheless i will keep the number of such preprocessor #defines
small (certainly below 10).

depikt also provides a way of inlining icons (and images at all) in
python code now. depikt.gdk_Pixbuf.serialize() renders gdk.pixbufs to
a representation in bytes objects of Python3. These are not really
well readable or usable, but python's array.array.fromstring() and
array.array.tostring() are used to provide well readable and well
code-usable representations of those bytes objects. There is in tools.tgz now, creating those array-representations
(arrays of unsigned 8-bit-ints). Again Python3 is essential here.

depikt also provides the standard dialogs in tools.tgz now - they use
a serialized (and public domain) "back"-icon of WindowsXP. The script is also a severe test of depikt's usability, since using
moreover grandchildren of depikt.Window and python threads -
unfortunately this script crashes sometimes due to the bad support for
widget destruction in depikt.

Again: I urgently need depikt for a large python project. Adapting
depikt for it will make depikt better usable and really stable
sometimes in 2010. depikt will prevail. There is no way for me without

Thanks for reading, DreiJane

More information about the Python-list mailing list