Re: [PyQt] PyKDE4 Update
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. 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. 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. 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 the threading API sounds like a big can of worms for Python programs running on CPython. Someone can speed that up by volunteering to debug bindings for those packages AND producing test code/examples or (at best) a tutorial. Docs I can get for free from the h files. True, if someone is interested in an API and can help out, then it can be given high priority. cheers, -- Simon Edwards | KDE-NL, Guidance tools, Guarddog Firewall [EMAIL PROTECTED] | http://www.simonzone.com/software/ Nijmegen, The Netherlands | ZooTV? You made the right choice. ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] PyKDE4 Update
On 03.09.07 20:52:31, 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. There are issues of release schedules, bug fixes, and general maintenance that increase more than linearly with the size of the code base. I agree about threadweaver, but I'm not so sure about nepomuk and knewstuff. Well nepomuk is still very young and doesn't have too many users yet, but that will change over the KDE4 lifetime - so maybe leave it out for now. But knewstuff could IMHO be really useful for PyKDE programs that want to be extendable by providing plugins in python. The second issue is why I'm going to insist on demo code. I can get sip to generate code for all three of those (already have) and with a few more hours work could get them to compile. But in the process of doing that, I have to make choices about things to leave in and leave out (the set of h files that installs is not sufficient, for example), as well as handwrite some code. I know nothing about threading or knewstuff, and last I heard, Nepomuk was a 14th century martyr and patron saint of Bohemia. LOL. I'll be happy to put together a tarball to play with with any or all three of those, but none is going into PyKDE or anything else I release until I'm confident that they work and users can figure out how to apply them. Learning threading or symantic desktops is not high on my list of priorities, but I'll get to it eventually (a year or two). Someone can speed that up by volunteering to debug bindings for those packages AND producing test code/examples or (at best) a tutorial. Docs I can get for free from the h files. Did you or Simon ever think about porting the already existing tests from kdelibs to python? Thats not example applications in the meaning that they show users how to use the API, but they should cover all the specialities of the API. Andreas -- You're at the end of the road again. ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] PyKDE4 Update
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. 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 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.. 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. Andreas -- You teach best what you most need to learn. ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] PyKDE4 Update
Am Dienstag, 4. September 2007 10:56 schrieb Andreas Pakulat: but the threading API sounds like a big can of worms for Python programs running on CPython. Sure, since it involves playing games with the GIL. See below. Phil can tell you stories.. I don't know CPython and how Threading might influence the usage of it. Threading in CPython boils down to: no matter how many threads you're running in your process, the python code itself will always run non threaded, maintained by GIL, the Global Interpreter Lock. 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. Pete ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] PyKDE4 Update
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. ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] PyKDE4 Update
On 04.09.07 09:50:21, Jim Bublitz wrote: On Tuesday 04 September 2007 01:49, Andreas Pakulat wrote: Did you or Simon ever think about porting the already existing tests from kdelibs to python? Thats not example applications in the meaning that they show users how to use the API, but they should cover all the specialities of the API. That's a very good question. I think about it every time I see the 'tests' subdirectories when scrolling through the source trees. In the past (probably far past), they weren't very complete, but the indications are that they have very good coverage now, so it's worth looking at - I'll try to get to that fairly soon. I don't think it answers everything from an application programmer's point of view, but it would still be useful in improving PyKDE quality. Yes, thats what I meant the tests are good to make sure PyKDE doesn't break, but not necesarily to find out how to use it. I used to work for a company that made traffic signals and controls (although I wasn't in that division). The QC department there built a test fixture for the detectors they bury in the pavement to detect cars - like cars waiting to make a left turn. The test fixture could do the equivalent of detecting a car moving at 140 MPH (which wasn't likely to care about a signal light anyway). But when they got the detectors out in the field and buried in the pavement, they discovered they couldn't detect some kinds of large semi-trailer trucks stopped right on top of the detectors - I think it was because of some alloy used in the frames, or their height above the road. I get the same feeling about parts of PyKDE at times. Hehe :) Andreas -- Someone is speaking well of you. How unusual! ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] PyKDE4 Update
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 listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] PyKDE4 Update
On 04.09.07 11:35:07, Jim Bublitz wrote: 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 think you should update your KDE4 or remove your install dir. Current svn doesn't install that file anymore. It only installs the stuff in knewstuff2/core and the engine.h from knewstuff2 (and the ui header). Andreas -- Tomorrow, this will be part of the unchangeable past but fortunately, it can still be changed today. ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] PyKDE4 Update
On Monday 03 September 2007 09:48, Andreas Pakulat wrote: Just out of curiosity: Does PyKDE4 also work without GUI/X11 when one restricts himself to kdecore module? (I suspect so, but wanted to make sure) I was going to say probably, but KApplication is in kdeui now, so it seems less probable. The kdecore Makefile links in a bunch of X stuff, and kdecore also imports QtGui - I'm not sure at the moment if/why those are really necessary, but it wouldn't be hard to edit the Makefile and configure.py to find out. Thanks for the great work (also to Simon), I suspect I might get back to PyQt4/PyKDE4 hacking sooner, now that I've got the full KDE power at my hands :) Andreas PS: great work as in: having PyKDE4 ready for the 4.0 release, I didn't yet check it out, but the svn co is already running :) Thanks. JIm ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] PyKDE4 Update
On 03.09.07 21:08:15, Hans-Peter Jansen wrote: Am Montag, 3. September 2007 18:14 schrieb Jim Bublitz: The module lineup is about the same as PyKDE3, with a few changes. kfile has been rolled into the kio module, kabc/kresource are dropped, kmdi no longer exists, kspell is now in kdecore/kdeui as Sonnet, the solid module has been added, along with (tentatively) two modules that allow scripting plugins for the Kate editor. Could you elaborate the reasoning behind dropping kabc/kresource briefly? Is it missing upstream also? Yes it is. There's some other things that might be cool to have in pykde4, like knewstuff, nepomuk and possibly threadweaver as well... Andreas -- Write yourself a threatening letter and pen a defiant reply. ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] PyKDE4 Update
On Monday 03 September 2007 12:08, Hans-Peter Jansen wrote: Awesome, Jim. Am Montag, 3. September 2007 18:14 schrieb Jim Bublitz: The module lineup is about the same as PyKDE3, with a few changes. kfile has been rolled into the kio module, kabc/kresource are dropped, kmdi no longer exists, kspell is now in kdecore/kdeui as Sonnet, the solid module has been added, along with (tentatively) two modules that allow scripting plugins for the Kate editor. Could you elaborate the reasoning behind dropping kabc/kresource briefly? Is it missing upstream also? Yeah - I don't know where they've gone. Are they in kdepim? They're no longer in kdelibs (or kdebase, or kdesdk). I don't download all of the source packages (I'm bandwidth limited). I'll be happy to take a look at them if they've moved. If they've moved, the only concern is if they've picked up new dependencies - otherwise putting them back isn't too much work. I think kmdi is just gone, but I haven't searched for that either. There is some MDI support in Qt4, but haven't looked at that much yet either. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] PyKDE4 Update
[... Forgot to CC the list ...] On Monday 03 September 2007 23:05:03 Jim Bublitz wrote: On Monday 03 September 2007 12:08, Hans-Peter Jansen wrote: Awesome, Jim. Am Montag, 3. September 2007 18:14 schrieb Jim Bublitz: The module lineup is about the same as PyKDE3, with a few changes. kfile has been rolled into the kio module, kabc/kresource are dropped, kmdi no longer exists, kspell is now in kdecore/kdeui as Sonnet, the solid module has been added, along with (tentatively) two modules that allow scripting plugins for the Kate editor. Could you elaborate the reasoning behind dropping kabc/kresource briefly? Is it missing upstream also? Yeah - I don't know where they've gone. Are they in kdepim? They're no longer in kdelibs (or kdebase, or kdesdk). I think akonadi[0] replaces it. [0] http://pim.kde.org/akonadi/ Regards, ismail -- Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] PyKDE4 Update
On 03.09.07 13:05:03, Jim Bublitz wrote: On Monday 03 September 2007 12:08, Hans-Peter Jansen wrote: Awesome, Jim. Am Montag, 3. September 2007 18:14 schrieb Jim Bublitz: The module lineup is about the same as PyKDE3, with a few changes. kfile has been rolled into the kio module, kabc/kresource are dropped, kmdi no longer exists, kspell is now in kdecore/kdeui as Sonnet, the solid module has been added, along with (tentatively) two modules that allow scripting plugins for the Kate editor. Could you elaborate the reasoning behind dropping kabc/kresource briefly? Is it missing upstream also? Yeah - I don't know where they've gone. Are they in kdepim? They're no longer in kdelibs (or kdebase, or kdesdk). kabc and kresources are both in kdepimlibs, the dependecy for kdebase (for ldap stuff) besides kdelibs. akonadi is AFAIK not ready for 4.0, i.e. its not integrated in kdepim yet. Having kdepimlibs in PyKDE4 might be a good idea as well, I haven't looked into it too much but I think quite some of the libs will make it possible to integrate python apps with the KDE4 PIM-Stuff (kontact database, calender and whatnot). I don't download all of the source packages (I'm bandwidth limited). I'll be happy to take a look at them if they've moved. If they've moved, the only concern is if they've picked up new dependencies - otherwise putting them back isn't too much work. Do you know websvn.kde.org? Pretty neat, also lxr.kde.org can help if you know already what you're looking for in svn. I think kmdi is just gone, but I haven't searched for that either. There is some MDI support in Qt4, but haven't looked at that much yet either. kmdi is dead and thats a good thing ;) Qt itself just has the similar thing it had in Qt3 wrt. MDI, basically what designer uses. There is a qmdilib library floating around on kde-apps.org, but thats external and I doubt Phil wants to provide packages for that. Also there's a new library-like module - kdevplatform which will provide a powerful Ui, targetted at IDE-like applications (ok, enough advertisement). I'm not sure though wether its possible to have python-plugins for kdevplatform, although it uses the same mechanisms as Qt Designer plugins under the hood and the module is still pre-alpha (as the rest of kdevelop) and won't be released with kde 4.0.0. Andreas -- Your motives for doing whatever good deed you may have in mind will be misinterpreted by somebody. ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] PyKDE4 Update
On Monday 03 September 2007, Andreas Pakulat wrote: Also there's a new library-like module - kdevplatform which will provide a powerful Ui, targetted at IDE-like applications (ok, enough advertisement). I'm not sure though wether its possible to have python-plugins for kdevplatform, although it uses the same mechanisms as Qt Designer plugins under the hood and the module is still pre-alpha (as the rest of kdevelop) and won't be released with kde 4.0.0. I think there's a Google Summer of Code project to implement all the Python stuff for KDev* (not sure if in KDevelop or KDevPlatform), I suspect there's PyKDE integration in there too. John. -- ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] PyKDE4 Update
On 03.09.07 23:16:47, John Layt wrote: On Monday 03 September 2007, Andreas Pakulat wrote: Also there's a new library-like module - kdevplatform which will provide a powerful Ui, targetted at IDE-like applications (ok, enough advertisement). I'm not sure though wether its possible to have python-plugins for kdevplatform, although it uses the same mechanisms as Qt Designer plugins under the hood and the module is still pre-alpha (as the rest of kdevelop) and won't be released with kde 4.0.0. I think there's a Google Summer of Code project to implement all the Python stuff for KDev* (not sure if in KDevelop or KDevPlatform), I suspect there's PyKDE integration in there too. No, you misunderstood that (apart from PyKDE not being there when GSoC started), the python support in KDevelop is about having a language plugins that provides things like code-navigation, code-completion, extended highlighting and eventually even refactoring. All this is coded in C++ (which was quite a challenge for my student to be honest). Andreas -- You love your home and want it to be beautiful. ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] PyKDE4 Update
On Monday 03 September 2007 12:52, Andreas Pakulat wrote: On 03.09.07 21:08:15, Hans-Peter Jansen wrote: Am Montag, 3. September 2007 18:14 schrieb Jim Bublitz: The module lineup is about the same as PyKDE3, with a few changes. kfile has been rolled into the kio module, kabc/kresource are dropped, kmdi no longer exists, kspell is now in kdecore/kdeui as Sonnet, the solid module has been added, along with (tentatively) two modules that allow scripting plugins for the Kate editor. Could you elaborate the reasoning behind dropping kabc/kresource briefly? Is it missing upstream also? Yes it is. There's some other things that might be cool to have in pykde4, like knewstuff, nepomuk and possibly threadweaver as well... It's not a problem to create more bindings - I ran through the 3 you mentioned and have sip files and could have compiling code with a few more hours work. However, there are a couple of problems with that that need to be addressed. 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. There are issues of release schedules, bug fixes, and general maintenance that increase more than linearly with the size of the code base. The second issue is why I'm going to insist on demo code. I can get sip to generate code for all three of those (already have) and with a few more hours work could get them to compile. But in the process of doing that, I have to make choices about things to leave in and leave out (the set of h files that installs is not sufficient, for example), as well as handwrite some code. I know nothing about threading or knewstuff, and last I heard, Nepomuk was a 14th century martyr and patron saint of Bohemia. I'll be happy to put together a tarball to play with with any or all three of those, but none is going into PyKDE or anything else I release until I'm confident that they work and users can figure out how to apply them. Learning threading or symantic desktops is not high on my list of priorities, but I'll get to it eventually (a year or two). Someone can speed that up by volunteering to debug bindings for those packages AND producing test code/examples or (at best) a tutorial. Docs I can get for free from the h files. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] PyKDE4 Update
On Monday 03 September 2007 12:08, Hans-Peter Jansen wrote: Awesome, Jim. Am Montag, 3. September 2007 18:14 schrieb Jim Bublitz: The module lineup is about the same as PyKDE3, with a few changes. kfile has been rolled into the kio module, kabc/kresource are dropped, kmdi no longer exists, kspell is now in kdecore/kdeui as Sonnet, the solid module has been added, along with (tentatively) two modules that allow scripting plugins for the Kate editor. Could you elaborate the reasoning behind dropping kabc/kresource briefly? Is it missing upstream also? From the comments downthread, would you want kabc or akonadi? Do they need to part of PyKDE, or can they be in a separate package (along with other add-ons)? Can you write some example code for kabc? I'm still skeptical about the PyKDE3 version, as there was some class or global variable or something I had to omit from the bindings. I'd like to know these are usable before releasing them. Jim ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
