[PyQt] PyKDE4 Update

[Andreas Pakulat]

On 04.09.07 09:35:34, Jim Bublitz wrote:
> 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.

I'm not sure about that, KTextEditor already provides a plugin class and
at least some plugins, like word completion, use that interface instead
of the Kate::Plugin. Also the interfaces in kdesdk/kate/interfaces are
not installed, so they might not be meant to stay (or somebody just
forgot a CMakeLists.txt file), I'll ask the kwrite devs..

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

Agreed.

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

Well, kdeprint is pretty broken at the moment anyway. Its supposed to
get basic fixing for the 4.0 release, but that mainly means making the
most-used options useable again.

Andreas

-- 
Your lucky color has faded.