Hello, 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 the utf-8-code sqlite works with alone. And in the long run one of the python-API of the monet database perhaps A preprocessor macro -DDEPIKT_USES_BYTES decides, whether depikt communicates with python via bytes or (unicode) strings - the actual setting in setup.py 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 source code 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 setup.py, i will not automatize the use of the output of pkg-config for gtk. But that really doesn't need much C- knowledge (a little bit knowledge of how C-compilers work is essential though). depikt comes with new features: depikt.gdk_threads_enter (and leave) is supported. Again controlled by a preprocessor macro DEPIKT_SUPPORTS_THREADS. #ifdef DEPIKT_SUPPORTS_THREADS (what is the default), each gtk.main() has to be prepended by depikt.gdk_threads_enter(). Admittedly gtk-threads aren't really intensively now. Since you must arrange setup.py 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 these bytes objects. There is PixbufLister.py 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 Dialogs.py 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 depikt. Thanks for reading, DreiJane -- http://mail.python.org/mailman/listinfo/python-list