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. _______________________________________________ PyQt mailing list [email protected] http://www.riverbankcomputing.com/mailman/listinfo/pyqt
