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 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
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