[PyQt] PyKDE4 Update
apaku at gmx.de
Tue Sep 4 09:49:11 BST 2007
On 03.09.07 20:52:31, Jim Bublitz wrote:
> The first is how large should PyKDE be? At some point I'd want to start
> splitting stuff off into a second package, and all 3 you mentioned would be
> good candidates for that. They're not really central to kdelibs for what I
> see as the average user. There are issues of release schedules, bug fixes,
> and general maintenance that increase more than linearly with the size of the
> code base.
I agree about threadweaver, but I'm not so sure about nepomuk and
knewstuff. Well nepomuk is still very young and doesn't have too many
users yet, but that will change over the KDE4 lifetime - so maybe leave
it out for now. But knewstuff could IMHO be really useful for PyKDE
programs that want to be extendable by providing plugins in python.
> The second issue is why I'm going to insist on demo code. I can get sip to
> generate code for all three of those (already have) and with a few more hours
> work could get them to compile. But in the process of doing that, I have to
> make choices about things to leave in and leave out (the set of h files that
> installs is not sufficient, for example), as well as handwrite some code. I
> know nothing about threading or knewstuff, and last I heard, Nepomuk was a
> 14th century martyr and patron saint of Bohemia.
> I'll be happy to put together a tarball to play with with any or all three of
> those, but none is going into PyKDE or anything else I release until I'm
> confident that they work and users can figure out how to apply them. Learning
> threading or symantic desktops is not high on my list of priorities, but I'll
> get to it eventually (a year or two). Someone can speed that up by
> volunteering to debug bindings for those packages AND producing test
> code/examples or (at best) a tutorial. Docs I can get for free from the h
Did you or Simon ever think about porting the already existing tests
from kdelibs to python? Thats not example applications in the meaning
that they show users how to use the API, but they should cover all the
specialities of the API.
You're at the end of the road again.
More information about the PyQt