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