[PyQt] PyKDE4 Update

[Jim Bublitz]

On Tuesday 04 September 2007 10:09, Andreas Pakulat wrote:
> On 04.09.07 09:35:34, Jim Bublitz wrote:
> > 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..

The kdesdk files provide the kate objects (application, documentManager, 
mainWindow, view). There's already a working application for KDE3 with its 
own set of bindings.

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

I don't know if anyone's ever used it from PyKDE3, and I've never written any 
code against it - but it always compiles. In fact it's the least troublesome 
module in PyKDE.

But for example, knewstuff installs dxsengine.h in users include/ directory. 
dxsengine.h depends on coreengine.h, which isn't installed. Not knowing 
anything about knewstuff, I don't know if I should a) drop dxsengine from the 
module or b) add coreengine.h (and associated sip file) to PyKDE or c) keep 
dxsengine but eliminate the dependency on coreengine (coreengine provides a 
base class  - I can not tell sip about the base class and the dependency is 
solved, but all inherited methods are lost) or d) write some code manually to 
fix the problem (I can restore some or all of the inherited methods manually 
without coreengine or do other things). 

I can make any of those options work syntactically. Someone familiar with 
using knewstuff in applications should be able to provide or determine which 
is the correct choice.  That someone probably isn't the developer, because 
(and I do this myself) developers have one view of how their classes should 
be applied, while users may come up with some cool new way to use something 
that the developer hadn't foreseen.

Some of that is just part of how code evolves - the reason we don't all just 
stop at v1.0.0. But the initial decisions I make might leave the module 
totally unusable, or I might spend 10-15 hours wrestling with code to put in 
something there's no possible application for. I've done both, but I'd like 
to eliminate the first and minimize the second. And I'd like to be able to 
verify (with running code) that the choice was correct.

Jim