D
DreiJane
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 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 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 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 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() 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 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 those 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
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 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 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 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() 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 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 those 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