[PyQt] PyKDE4 Update

[Jim Bublitz]

On Tuesday 04 September 2007 01:56, Andreas Pakulat wrote:
> 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.

Someone is interested in doing plugin code for Kate, and needs 
kdelibs/interfaces/ktexteditor and also kdesdk/kate/interfaces/kate.

You're right though - application bindings for nearly any app would be huge 
and contain lots of useless stuff.

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

As in the example above, someone needs stuff from kdelibs and kdesdk. For 5 or 
6 files from kdesdk, it isn't worth an entire kdesdk package. 

Not having done this, I might have a different opinion in the future, but 
there are two things I'd consider. One is: "where are the h files?" If 
they're not normally installed (meaning users need a KDE source tarball to 
compile the bindings), then I'd be less likely to distribute the bindings 
generally.  I might do something custom if I have the time. OTOH, if the 
bindings are packaged with KDE, then that's a little less of a concern (but 
still makes it difficult to patch between releases, for example).

The other thing is that the point of doing this is to make things accessible 
and easy for Python programmers. I'd agree it makes sense to follow the KDE 
divisions where possible, but the standard I'd use is "what makes sense from 
a Python programmer's point of view?".  If that means combining code from 
kdelibs and kdesdk into a single package (although separate modules in the 
kate case), then I'd do that.

There's another standard that relates to "what's necessary to actually build 
the module?", which is why the kdeprint module gets complaints about having 
all kinds of things the developers want to be "internal". If I chop out 
everything marked "internal", there's not enough there to compile what's 
left, which is why all of those "internal" h files end up in the user's 
include directory in the first place.

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

It's relatively easy for me to track even big changes in the code underlying a 
module (it's mostly done automatically), so I wouldn't be opposed to 
including things early. That gives Python users access to new KDE tech as 
early as possible, which I think is a good thing. But see my next comment.

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

I don't know either, which is why I'd want someone who does know (or is 
willing to find out) to evaluate and critique what's produced in terms of 
bindings before unleashing them on the general Python public and then finding 
out it's useless. That kind of thing just makes PyKDE look bad and doesn't 
provide anything except frustration to users.

All I deal with generating bindings is syntax - everything compiles, but it 
may not be usable.

Jim