[PyQt] PyKDE4 Update
apaku at gmx.de
Tue Sep 4 09:56:24 BST 2007
On 04.09.07 08:19:10, Simon Edwards wrote:
> 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.
> I was think about that the other day when I realised that Kate and its .h file
> isn't even in kdelibs, but kdesdk or something.
Thats not quite right and Kate the application was _never_ in kdelibs,
not in kde3 or any time before that. Only two things from the
kate-developers dwell inside kdelibs: The KTextEditor library and the
Kate KPart. So for example KWrite in kdebase can provide a good editor
using Kate's KPart and sharing code with the full-fledged Kate Editor
from kdesdk. I don't think you want to provide bindings for Kate the
application from kdesdk.
> We could put everything in
> PyKDE4 and create some extra configure time flags for turning certain
> dependencies on or off. e.g. "just give me bindings for everything in kdelibs
> and that's all" or "give me the lot"). A second package PyKDE4EverythingElse
> has its advantages too. For a start, we might get more consistent and clearer
> packaging. With less of this "Dammit! XYZ compile their pykde4 package with API
> ABC turned off! but everyone else has it compiled in!". PyKDE4 would then
> depend on kdelibs and maybe kdepimlibs, like kdebase does. And
> PyKDE4EverythingElse could have much large dependencies like, well, everything
I don't think thats a good idea. IMHO a bunch of separate binding
packages similar to how the KDE modules are structured is better. So
we'd have pykde4-kdelibs, pykde4-kdepimlibs, pykde4-kdeedu,
> Another API which I would like to have bindings for is Marble. I was a bit
> surprised to find that it isn't part of kdeui, but kdeedu module.
Well, thats quite natural. The rule for inclusion in kdelibs is at least
3 uses outside of kdelibs and I suspect that a shared lib for Marble
currently doesn't have that many users. Apart from it being very young
and eventually having to mature more.
> >Learning threading or symantic desktops is not high on my list of priorities,
> >but I'll get to it eventually (a year or two).
> Semantic desktop API is probably useful,
But as I said to Jim still very young and little uses, so maybe
something that can be pushed back until 4.1 or so..
> but the threading API sounds like a big can of worms for Python
> programs running on CPython.
I don't know CPython and how Threading might influence the usage of it.
However ThreadWeaver is built on top of QThread, so if CPython has a
problem with ThreadWeaver it also has with QThread, which would be
pretty bad. Threadweaver is not another abstraction from system-thread
You teach best what you most need to learn.
More information about the PyQt