[PyQt] PyKDE4 Update
jbublitz at nwinternet.com
Tue Sep 4 19:35:07 BST 2007
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.
More information about the PyQt