James Emerton <[EMAIL PROTECTED]> wrote: >>> That's a valid point, but I don't think it needs to be a 'totally >>> separate project.' I understand the potential for incompatibility >>> with two versions of PyQt, but what if they had different names? They >>> can still be built from the same codebase, with %Feature directives. >> >> I believe a Python-only implementation would be easier to work on. See >> also the mail by David Bobble with which I totally agree. > > This depends on where you draw the line. A total Pythonic > implementation of Qt is infeasible. The PyQt community is not large > enough to develop a stable and mature API. I do not mean to imply a > lack of ability, simply a lack of manpower. The Qt 3.3 docs list 3626 > unique method names, with many of them appearing in multiple classes. > That's an awful lot of maintenance!
Maybe I wasn't clear. What I was proposing was *not* to create a full Qt wrapper, but to introduce *helpers* to manage normal Qt objects in a more Python way. If you look into the examples I wrote down yesterday, you'll see it's mostly about creating or accessing Qt objects in more pythonic way, not wrapping each and every object and each and every method. -- Giovanni Bajo _______________________________________________ PyKDE mailing list PyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde