[PyQt] PyKDE4 Update

[Andreas Pakulat]

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

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,
pykde4-kdesdk

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

Andreas

-- 
You teach best what you most need to learn.